Iosevka is the king of scalable terminal/programming fonts. I'm not sure why, maybe it's because the glyphs have lines and angles that look "terminal-y" in the same pleasing way Terminus and the 3270 font do whilst avoiding the problems that accompany trying to scale a pixel font.
Then you are probably not interested in this work at all. It is meant to develop Lisp—a language whose primary advantage in 2026 is ergonomics to humans, particularly a certain kind of human. If you're doing 100% agentic development, that advantage disappears and you might as well use something popular and statically typed, like Rust or TypeScript.
> If you're doing 100% agentic development, that advantage disappears
I beg to differ. Turns out, Lisp REPL - an actual, "true" REPL, not something like Python's (which is not the same), is an enormous multiplier for agentic workflows.
a) Lisp code can be very terse yet retain its readability - it never becomes cryptic like APL. Therefore, it's more token efficient. It was actually proven that Clojure is one of the most token-efficient "mainstreamish" PLs. https://martinalderson.com/posts/which-programming-languages...
b) When you give an LLM a closed loop system where it can evaluate code in a live REPL and observe the results, it stops guessing and starts reasoning empirically. Instead of predicting what code will do, it can run it, read the output, adjust, and iterate - the same way a skilled human developer works. Incremental evaluation of forms maps naturally to how an LLM generates tokens.
This isn't some theoretical hand-waving - I experience it every day - my WM on Mac is yabai that gets controlled via Hammerspoon, which uses Lua, which means I can use Fennel, which means I can use Lisp REPL. I would give the LLM a task, something to do with my app windows - it connects to the live REPL and starts analyzing, prototyping and poking into things interactively.
All my custom MCPs are written in babashka (Clojure) https://github.com/agzam/death-contraptions - whenever there's a problem or I need to improve my AI harness, LLM just does it from "inside out" and it takes less time and fewer tokens.
My main editor is Emacs - LLM can fully control it. I can make it change virtually any aspect of it. To load-test the MCP that does that, I made it play Tetris in Emacs. And not just to run it, but to play it for real - without losing. It was insane.
And of course, day-to-day I have to deal with non-Lispy, non-homoiconic languages more. And to be honest (even though of course I'm biased in this) static type systems is the exact thing in practice where their advantages feel like stop making any big difference. While Lisp REPL feels far more useful.
Technically, I think this is meant to develop Coalton, which is also statically typed and incredibly effective as a language for agents. All those ergonomic benefits that humans enjoy also allow AIs to develop lisp systems quite rapidly and robustly.
Not true. Are people not interested in archeology or history or museums? Denying such things as invalid is offensive. There are projects to reproduce things from ancient history like the Lycurgus cup.
I keep hoping the Common Lisp community will step up and deliver better Visual Studio Code support. Asking new devs to learn Emacs, alongside all of Lisp's idiosyncrasies, is too tall an order. I bro'd through it in the 90s but today's new devs have been spoiled by modern UIs (and that's a good thing) and shouldn't have to cope with Emacs and its stubborn retroness.
Seeing something like this is a step in the right direction.
> will step up and deliver better Visual Studio Code support.
In order to understand what it means to have true Lisp support in an editor/IDE, you have to understand what Lisp is about. Lisp is not just a syntax - it is a live, interactive, self-modifying computational environment. VSCode, like most editors, treats code as text files and execution as a subprocess you invoke. That model is fundamentally at odds with how Lisp development works.
Yes, there are some extensions like Calva and Joyride that attempt some serious work - but the host editor's mental model is always pushing back. So really it ain't about syntax highlighting, bracket matching, and a REPL pane you can type into.
That is something that "new devs" don't understand about Emacs. It's not about the features, nor about its looks - it's about what fundamentally it is - the Lisp REPL - a live, interactive, self-modifying computational environment. Something that VSCode could never truly become. I could never write some code in some scratch buffer, eval it and change some aspect of my editor - in Emacs, I can. And I wouldn't even have to save that code anywhere. In order for VSCode to become like that, you'd have to break its fundamental model, which causes it to become something else - not VSCode.
Therefore, if someone has no interest in Lisp just because VSCode doesn't support it nicely, well, honestly - it's their loss. You know, just because a megacorporation threw billions at developing it, it doesn't mean it's objectively better - there are still other, more pragmatic alternatives. F-35s that cost $1.7 trillion may look shiny and intimidating, but when it comes to the "real deal" - much cheaper, ugly, purpose-built, A-10 Warthog proves its worth, and does it so well that the Pentagon just can't seem to be able to retire it.
I don't think Emacs is that hard to get used to, as long as you don't expect to replicate your IDE experience right away. Like if you use Jetbrains products, expect to switch to Emacs and get the same approach right away you will just have a very very bad time.
I started using Emacs recently for Orgmode as an alternative to Obsidian, first I just thought I'd try using for about a month, and if I don't like it I'd quit. But I kept using it month after month, eventually switching it completely. It's been over a year since then.
Then I also figured I'd try some lisp since that's what it's used for, and installing SBCL and Sly was super easy. And then the actual experience of writing Lisp was easy too.
This is on Windows 10 too. You can install and update Emacs and SBCL for Common Lisp very easily with Scoop. It might not be the optimal way to do it, but it works perfectly fine.
For comparison I tried installing Lem on Windows and I couldn't get it to work.
Yeah, I mean there is some support for various editors (https://lispcookbook.github.io/cl-cookbook/editor-support.ht...) including VS Code (https://lispcookbook.github.io/cl-cookbook/vscode-alive.html), but it's kind of rough (https://blog.djhaskin.com/blog/experience-report-using-vs-co...) and not exactly feature-complete with the emacs experience, plus you're still left having to figure out how to install and setup a Lisp implementation and quicklisp. I like that mine solves those for a newcomer, especially on Windows. (I myself use vim + slimv, but even that isn't quite at parity in some respects with emacs. The biggest weaknesses are around debugging, especially in the presence of multiple threads. But the essentials do work (stepping, eval-in-frame, continuing-from-a-stack-frame, selecting the various types of restarts, compiling changes before selecting restarts) so I'm still fairly productive and don't feel like I'm lacking anything sorely needed for professional work. I've hacked together some automatic refactoring bits as well, which emacs doesn't have either, and I'm eventually going to make a separated GUI test runner.)
I've been kicking the tires with mine a little bit yesterday and today, I think it's quite good for the beginner experience. But I'm constantly of two minds about reporting some feature requests. The project's primary goal seems to be existing as a stepping stone to even see what Lisp (and especially Coalton) is really all about before "graduating" to something like emacs, it feels like a secondary goal (though it is mentioned as a goal) to be usable by professionals as well, but there's inherent tension there. That's also been a weakness with the other editors: anyone already comfortable with Lisp development, professional or not, in emacs or not, isn't very likely to give the time of day to some new thing that's almost certainly not going to be as good as what they're used to. And so the new thing doesn't get the attention and feedback from experienced developers and the gap never closes.
> today's new devs have been spoiled by modern UIs (and that's a good thing) and shouldn't have to cope with Emacs and its stubborn retroness.
Two words: Programmable editor.
One of the best advantages of Lisp is the ability to metaprogram. After solving a problem, you find that your code can fit other cases and then you you write a program that will produce the relevant code for those cases. In most other PL you would have to write the slightly different code again or use a template language.
Once you get accustomed to that, you will start to decompose other parts of your workflow in smaller building blocks and realize that only a few parts differ, but they all fits the same workflow. And one of the main realization 99% of them are text, act on text, and produce text. So what you really need is a framework around text, not a bespoke assemblage of tools.
With Unix, you have the text processing tools and vi (some would say ed). All centered around the terminal, the shell and files. Emacs is another version with a lisp vm, a collection of functions and the buffer as the interface. A third version is acme with buffers and mouse clicks as commands. The idea here is to be able to build small tools that can take care of the misc. things we need to do while writing programs. From navigation to analyzing, from formatting to building, and the myriads things in between.
Modern UIs are good for beginner and light usage. Or if you're lucky, they have your specific workflow neatly packaged in some plugins. But when you get tired of having another helpful "update" messing your muscle memory, or want to establish an efficient workflow with some external program (A CL lisp runtime in your case), that's when the weakness appears.
I'm talking about beginners, not seasoned Lisp hands, most of whom—until the great boomer dieoff occurs at least—are already comfortable in Emacs. If you're still just finding your feet in Lisp, you're not aware enough of its tremendous power to miss it from your IDE. You're just wondering why you have to Escape Meta Alt Control Shift to get anything done instead of, you know, just using the menu and mouse commands and keyboard shortcuts that literally everyone else uses.
If the beginners are curious about Lisp and insist on using VSCode, they can install Calva and try Clojure. It takes less than a minute and it has a really good "quick start" guide. There's no rule that says you have to get into Lisp specifically via SBCL. Once you grok structural editing and REPL-driven workflow, jumping between different Lisp dialects is not that hard.
And if a programmer refuses to learn a new language, technique or paradigm just because their favorite editor doesn't support it... well, that is sad, but also - not everyone has to be passionate about their work, huge sectors of the economy are driven by mediocre players and that is just fine. Passionate programmers sooner or later find their way to Lisp.
You can always start the REPL on its own and start playing that way.
Or use something like:
sbcl --load <filename>
Sly/Slime is not essential to play around with Lisp. Emacs just has the right architecture for an REPL workflow. You can do REPL development with Sql and various other programs in Emacs.
Something like SLIME isn't essential to execute Lisp code, you're right, but it is essential in order to understand the efficiencies afforded by interactive development, which may as well be one of the pillars of the language, since "garbage collection" and "an object system" aren't in and of themselves differentiators anymore*. Using something like SLIME also takes a lot of the pains that people have with Lisp away, namely balancing parens and indenting code correctly. People who do the "I'll use my own editor" approach to beginning Lisp usually write things that look like:
(defun myfun(x)
(let (x)
(setq x 5)
(when (eq x 6)
(print "6")
)
)
)
Which is absolutely not what Lisp code should look like. Emacs-and-kin don't outright stop that, but the defaults are such that it's less likely.
____
* Of course, technically, CLOS is something to behold. But you won't sell someone on Lisp because it can do "OOP".
Interactive development is because Common Lisp runntime has the concept of images and systems. Just like you start you OS and do things with it, you start the Lisp runtime and do things with it. It’s a point A to point B type of interaction like running a script. Smalltalk, SMl, a modern web browser,… has the same kind of interaction. It’s not dependent on any editor.
Also automatic idiomatic formatting of lisp code is possible in any editor as long as they have the settings for it. Not sure how Emacs is the gatekeeper on that one.
Well, technically Windows 2.1 (released May 1988) came before OS/2 1.1 (released October 1988). OS/2 1.0 was text-only. So at least for 5 months in 1998, Windows technically beat OS/2.
And OS/2 1.1 was very similar to Windows 2.1, so it's arguable if it was actually much better.
OS/2 1.2 was a massive leap though, not only beating Microsoft GUI wise by a whole year, they even implemented tons of advanced features that we didn't see until Windows 95.
When I started working at Novell in October 1988, I was on the OS/2 team. The version I installed first was 1.0 so I remember that there was no GUI. A few months later we got the update (1.1) with the GUI.
What I remember the most is that they ordered us memory expansion cards that gave us an extra 4MB of RAM for a total of 5MB. I didn't see the actual invoice, but I remember them telling me that the expansion card cost about $2,000. I try to remember that when I complain about memory DIMMs measuring in the dozens of GB going up a bit in price.
That was the slogan of OS/2 2.0. But by then where Windows 3.x was already out and in 386 Enhanced Mode, more than good enough. It also had the extra "escape hatch" of being able to quit to real DOS if a DOS box didn't work.
OS/2 1.x's DOS box was bad, with lots of limitations, which isn't good when most existing PC apps are DOS apps. As for GUI, well, lets call the Presentation Manager 1.x v Windows 2.x a no-score draw.
> And yet it failed in the common user's perspective
In Germany, the situation was different: there, at that time OS/2 (in particular OS/2 3.0 Warp) had quite a bit of popularity among common users because Escom and in particular Vobis (the latter was an at that time ultra-successful chain for selling computers in Germany) decided they want to challenge Microsoft's de-facto monopoly on operating systems of that time by also selling PCs that had OS/2 pre-installed (you only got DOS/Windows installed for an upcharge):
"Als die deutschen Computerhändler Vobis und Escom ankündigten, auf ihren PCs zukünftig OS/2 vorzuinstallieren und Windows nur noch gegen Aufpreis anzubieten, übte Microsoft massiven Druck auf die beiden Computerhändler aus. So schloss Microsoft Vobis vom Beta-Programm von Windows 95 aus, bot für die Zukunft Windows-Lizenzen nur zu wesentlich schlechteren Bedingungen an und versuchte, Vobis dazu zu zwingen, eine Verschwiegenheitserklärung zu unterzeichnen."
DeepL translation:
"When the German computer retailers Vobis and Escom announced that they would pre-install OS/2 on their PCs in the future and offer Windows only at an additional cost, Microsoft exerted massive pressure on the two retailers. For instance, Microsoft excluded Vobis from the Windows 95 beta program, offered Windows licenses in the future only under significantly worse terms, and attempted to force Vobis to sign a non-disclosure agreement."
"1995 setzte Vobis wegen Lieferterminverschiebungen der 32-Bit-Plattform Windows 95 darauf, Kunden standardmäßig das bereits erschienene 32-Bit-Betriebssystem OS/2 von IBM auf PCs vorzuinstallieren, wodurch OS/2 auf dem deutschen Markt einen größeren Bekanntheitsgrad als anderswo erreichte. Microsoft soll in der Folge versucht haben, Vobis die Lizenz für Windows 95 zu entziehen, was einen schweren wirtschaftlichen Nachteil für Vobis bedeutet hätte."
DeepL translation:
"In 1995, due to delays in the release of the 32-bit Windows 95 platform, Vobis decided to pre-install IBM’s 32-bit OS/2 operating system—which was already available—on PCs as standard, resulting in OS/2 achieving greater recognition on the German market than elsewhere. Microsoft is said to have subsequently attempted to revoke Vobis’s license for Windows 95, which would have caused Vobis serious financial harm."
Vobis also produced its own computer magazine named "Highscreen" (named after Vobis' brand name for their PCs) that also contained lots of beginner tips for OS/2 to get PC buyers accustomed to OS/2.
Coke Zero is sweetened with aspartame and phosphoric acid. It's just formulated differently to avoid the taste associated with Diet Coke, which some find unpleasant.
> Coca-Cola updated the recipe for Coca-Cola Zero Sugar in the US, quietly adding stevia to the existing blend of aspartame and acesulfame potassium (Ace-K) in late 2023/early 2024
This is what the word "bus" used to mean on a hardware level: a backplane of connections to which multiple peripherals could be attached. These days a bus is a LAN of point-to-point serial connections which, it turns out, is much more viable at the high communication rates demanded of modern hardware.
> hackernews: "Good. It's about time government took action. The only cure for these abusive capitalist companies is government regulation."
> government: passes law requiring age verification at the OS level
> hackernews: "Oh no! How could this happen? We have to fight this you guys. For sure if it weren't for big tech lobbyists we wouldn't have to worry about draconian laws like this."
You can ban social media for people under 16 without having age verification at the OS level. These things are not related. Age verification is not a technical problem.
And your position is that the government doing anything is bad, then? Better to just resign yourself to abusive capitalists? The position that you're mocking is the belief that some laws are good and some bad. The fact that you seem to find that objectionable is baffling.
It's twofold, these are laws that are delving more and more into regulating the personal lives of its citizens and as a side effect forcing the de-anonymization of the internet. This in a way that makes it easier for the government to track your internet usage and if we're talking OS level verification, maybe even more than just internet usage.
If you really want to go after abusive capitalists, then go straight to the source. Regulate the things that are making this ban look like a good idea.
We've already had reports of the UK's Online Safety Act resulting in a convenient uptick in defamation lawsuits. Certainly not because the government can now easily track who posted a tweet that ruffled the feathers of someone important. So yeah, at the cynical end, I question the motivation of these laws and at the charitable end, I worry about the direction these laws are moving and their impact.
Actually no. The position I'm mocking is that we can somehow implement enforceable age restrictions on digital platforms without a verification mechanism that extends to the client level, even to the hardware. I think we need to suck it up and accept that the free-wheeling 90s are over, and using computers, the internet, and technology in general will become a much more regulated activity in the very near future, which is going to suck for people who make touching computers their entire personality, but greater society has decided that protection from certain severe social harms is worth the price paid.
This isn't a real dichotomy. There's not a lever positioned between safety and freedom that people can collectively choose to shift one way or another. The best way to enhance safety is to directly ban the harmful behavior, not install cameras everywhere to make sure that only the right people fall victim to it. A panopticon is both less free and less safe than the world we have now, and a world where Meta and Google are ground into silicon dust is safer and more free.
Yes, but the government wants social media as long as it's their propaganda being pushed in there. That's why they love TVs. Now that no one uses TVs any longer exactly because we know it's just government mandated propaganda they have an issue.
Privacy and freedom are not the same thing. You can have lots of freedom with low level of privacy, but it's impossible to high privacy and high freedom at the same time.
reply