e3bc54b2

Funny, that.

Emacs-lisp is probably the single biggest Lisp in 2022, certainly by number of users, and most likely also by total SLOC in the wild.

I understand where you are coming from, but in my case having anything be auto-installed is just a pain. My distro of choice is NixOS where installing stuff works fundamentally different from most other distros. When I tried it, lsp-mode just wasn't aware of it (not sure if it does now, but considering this space is vast, it is simply impossible to support every distro out there). Which means automated installation simply didn't work and I had to spend lot of time finding issues. For Emacs newbie it was a terrible pain.

Compared to that, I was done setting up Eglot + language server in 2 minutes flat, there was no config needed and it Just Worked!

*eglot (short for Emacs polyGLOT)

And major difference is eglot is slimmer compared to lsp-mode, integrates with and relies on built-ins more (xref etc) rather than inventing its own paradigm, is less cluttered by default and IME less buggier than lsp-mode cludge and now comes with emacs so doesn't need any other packages (other than language servers themselves, of course).

OTOH lsp-mode supports more than 1 active language server per buffer, generally support more features of the protocol than eglot and installs servers automatically (which may be a feature or bug depending on your system).

It comes down to utility and personal preference, but I've used lsp-mode before, found it quite buggy and cluttered, moved to eglot and have near zero LSP config now.

Everyone's favourite subset of functional features is different, of course.

I am still early in my career. I'm still discovering stuff for first time. I've also found that I am much more likely to use streams, lambdas, Optional and predicates in code compared to my more experienced colleagues. My functions tend to be pure more often, code has more interfaces than inheritance and generally more unit testable. One of the surprising moments was learning Elixir and realising I'm already doing the pipe thing in Java with Optional.map().

Java will never shed its OO skin but it is starting to grow FP muscles in the right places.

> In my experience the Clojure community is pretty tone-deaf when it comes to critisim.

Its quite frustrating actually. The people who are likely to be greatest advocates of the language (its a new-age Lisp!) are likely to be vocal about its failings, and are also hit with worst reactions like being told their issues are not issues.

If you are already part of the team, Clojure folks are very friendly. I want to avoid saying cult, but sometimes it has characteristics of one.

Clojure has an OS/2 problem in that one of the biggest selling points is Java compatibility. But, clojure is different enough from Java, and that difference is actually another one of biggest selling points, that using Java libs from Clojure is not idiomatic (IMO) and uncomfortable as wrapping/calling Java libs increases through codebase. But, because Java libs already exist and are maintained, there is little incentive to actually implement and improve Clojure libs themselves. The bootstrap became its noose.

As someone who really really tried to like Clojure, here's the issues I faced, roughly in order starting from biggest:

1. No framework. Clojurists tend to prefer libraries and I would too, but for a newbie starting out, when every other language seems to have converged on one standard way of doing things (Spring, Rails, Phoenix, Django etc), Clojure just gets in the way with decision fatigue.

2. Leaky abstraction. At every level it is apparent that Clojure is hosted on JVM or Javascript. Simply knowing Clojure is not enough, and you have to understand the underlying semantics to know what is going on. Exception stack traces are excellent example.

3. Unmaintained libs. While the language is stable and libs are much more likely to work still, unmaintained libs often mean some stuff does not work or needs to be figured out. Often people just drop to using Java libs instead, but then the wrapping business tends to get tedious.

4. Java is improving faster with more pattern matching, records and functional programming features. Other JVM hosted languages are becoming less appealing.

> The price jump between levels is now a joke.

It has always been a joke. Now it just ain't funny anymore.

RSS feeds currently fill this role and honestly I don't feel the need for base torrent protocol to support it. It does its job and it does it well, same as RSS.

Nice! About time unilateral arbitrary bans on good tech by stupid beurocrats and naive courts gets challenged.

They're probably both flexing. TSMC is so valuable because Apple's reserved high end high volume orders allows them to expand capacity, Apple probably also is a tester for new tech.

They'll both come to terms in some middle ground. Apple has history of such flexing to force other parties to play nice.

Right, I am just as much of a n00b at crypto as next guy/gal, but here's my understanding.

GP mentioned that detecting switcheroo is not possible because both original and new secret will be encrypted by the same public key. Until the decrypted secret is actually used, we will not realise it.

But, if we track all the changes in git, and have more than one copy (you have them, right?) then it becomes quite easy to detect this. Goes more if git commit access is gated by SSH key or another secret/auth layer. And this, makes detecting and or rolling back a switcheroo possible.

OTOH if you already have another checksumming mechanism in place (oh hello there, git!) age can piggyback off that and ensure there's no switcharoo.

I am loving the latest Emacs Renaissance! All you can eat buffet, but you can take your lunch (and dinner) home :)

OTOH, org-mode already does this, without any need for external package and minimal config. It works really well, too!

As always, the answer with Open source is do it yourself, or sponsor someone else who can :)

Besides, for the privacy benefits it provides, its definitely good enough. You can also export data and have fancy graphs be shown with minimal effort.

As a fellow doom user, Emacs became lot more stable (and faster) after disabling bunch of default doom packages and modules. In its default config, doom really is intended for use on semi-modern processors with SSDs.That fancy modeline et al come at a cost.

When I first watched that movie I never thought it would be so on the point, just 15 years too early..

NixOS has a nice module that can be easily enabled. After that default DE durden can be invoked with single command and can be interacted with as a normal VM/Window alongside your existing DE.

Admittedly I haven't tries making it my default yet, but seemed fairly well adaptable for tiling WM/Openbox needs.

How about Arcan? [0]

It seems very well reasoned, has stable API, excellent backwards compatibility and does not require GPU and i5 as this one might? Its author also has proven record and actual experience, which I'm not sure authors hpf TFA have, judging solely from their writing.

0: https://arcan-fe.com/

I get resistance to C, it is quite simple and straightforward language, but pointers aren't for beginners.

But hey, scheme is nice. No manual memory management, as simple as it comes syntax, very little to get started, excellent REPL, if it were in my power, I'd go back to college and have my first programming class in Scheme.

> I think (because I have no experience) twins must have a deeper human connection

For all its worth, I know at least 2 pairs of twins who cannot stand each other.

Good god this is a great article!

Starting from TLDR at top, it is well reasoned, well sourced and very detailed.

And I agree, UPI should remain free, precisely to allow the vibrant ecosystem and innovation formed around it. Banks nowhere are known to be nice guys, even TFA gives multiple examples when they were dicks until forced down, and its no good idea why they should get paid for UPI transactions when they are already turning out profit from it.

Oh Python is definitely bad enough that people would want to give it up.

Its just that everything else is even worse for this use case, so nobody does.

That was fun read, thanks!

For future reference: https://www.gnus.org/stuff/pterodactyl/pterodactyl.html

Yep, that was Lars' doing as well. He ran like 1 years worth of Emacs builds on every commit to see where the big jumps occurred, dug down and fixed regressions. There were other people helping too, but I remember Lars being the driving force behind the endeavor.

Been reading Lars' bug hunt logs since it started and its amazing. Guy retired rich and instead of lazying around or doing vain publicity/philanthropy he chose to develop and maintain Emacs, all out in the open. Almost all the bugs fixed are also not his own. As a newbie Emacs user I reported a bug and Lars investigates and fixed it within couple of days! Real cool guy and we're quite lucky to have him around.

Perhaps you can write some articles using them, showing how they're better?

SBCL is de-facto most popular implementation of Common Lisp, if I dare say. It is free, it is well maintained, it is easily available, and it is fast. As a student/enthusiast, it doesn't get much better.

Lispworks/Allegro is better if specialized requirements or actual money is on the table. Lispworks supports mobile platforms IIRC which SBCL does not, for ex. But if all one needs is server side deployments or personal projects, there is no need, nor any use of commercial implementations, as good as they might be.

> I'm wondering why a family of languages should be this dependent on a specific editor...

As mentioned by others, its not. But Emacs is also a Lisp runtime. People who are attracted to Emacs eventually learn some Lisp (Emacs Lisp, closer to CL than Racket et al) or were attracted because of Lisp in the first place. As a result, the overlap between CL devs and Emacs users is naturally higher than that for other editors. This translates into people developing more and better tools for their editor, and higher popularity usually translated into more and better tools (with obvious exceptions).

As mentioned by other commenters, SLIME can be used with Vim too, if that's your thing. But just like SBCL, Emacs is kinda of de-facto editor of choice, not by force, but by love of its users :)

Thank you for detailed reply here and elsewhere in the thread. That probably took as much time as writing a new blog post, so it is really appreciated.

As mentioned before, as a newbie student of Elixir this is all very exciting. Please keep up the good work!