I've tried perhaps one third of the samples. All of them ran in 120 fps in 3840x2160 px in Firefox on Linux on my machine. Perhaps it is a configuration problem. My screen has a 120 fps refresh rate, so it probably is capped there.

Do you have a link to that patched version?

You mean such readable and understandable names like car, cdr, cadr, .... ? For the uninitiated, car is not about vehicles.

But you can use `first`, `rest`, etc. in new code. CL and Scheme are stuck with the old names for backward compatibility reasons going back over 60 years.

Clojure had a chance to do better because they were starting a new thing.

It's not necessarily a flaw with the language, in any case, just something I've noticed in Clojure articles.

I suppose I'm agreeing with the author - refactoring Clojure to make it more readable is a good idea.

> Clojure had a chance to do better because they were starting a new thing.

And it did. The seq abstraction is way more practical than the old-school list obsession in other Lisps. You get to treat collections uniformly while keeping the performance benefits of each implementation. Pretty smart move, honestly.

But sequences already existed in Common Lisp. The "list obsession in other Lisps" is largely people who don't actually use Lisp, IME.

That sounds like something someone unfamiliar with the subject would say.

While Common Lisp does have sequence functions, Clojure's seq abstraction is fundamentally different and more comprehensive: Clojure's seqs work uniformly across all data structures (vectors, maps, sets, strings, etc.), not just sequences; Clojure seqs are lazy by default; The seq abstraction is built around immutable data structures from the ground up; In Clojure, everything implements the seq interface - it's the primary abstraction, not just a library feature.

Common Lisp's sequences are more limited - they work on lists, vectors, and strings, but the interface isn't as pervasive or as foundational to the language design. Clojure made the seq abstraction central to how you work with any collection.

I really loved it for a virtual conference

Yes, nixpkgs is definitely missing the self-documenting part, or even the documenting part for most of it.

Don't forget the self-documenting aspect. The manual is included, the api documentation is included, you can ask emacs which command is executed when you click somewhere or when you press a button. I recently tried to do the same thing in Intellij, pita. Not only, can you find documentation, you can jump to the source code, inspect variable values at runtime, and debug or profile everything. All of that from inside the environment.

Absolutely!

Seems like the conceptual design helped with that too, reducing the activation energy needed for clear, interactive documentation. The code and the UI are both designed against the same set of consistent concepts, which naturally brings them together and, in turn, makes it so much easier to tie them from one to another. Simplest example: every interaction in the UI is a "command" and commands are reflected in elisp, so having a way to jump from an interaction to the corresponding code and documentation just makes sense. The documentation can be organized along the same conceptual lines as the code and the UI.

Emacs really is an amazing design study.

Dynamic scoping is a feature in the Emacs ecosystem. It plays a similar role to dependency injection in other languages. It is what allows you to change global state for some function call. Dynamic scoping together with buffer-local, file-local, directory-local variables is similar to scopes in dependency injection libraries --- a powerful organizational tool.

In practice it is difficult enough, to do the right date arithmetic using the datetime library in the right timezone.

There is a central configuration, see here https://news.ycombinator.com/item?id=43642743

One way to deal with large binary files is git-annex, it is as decentralized as git. But I dare say it lost to git-lfs, because Github and co weren't interested in hosting it.