alt.hn

1/12/2025 at 3:38:25 AM

Why I Chose Common Lisp

 https://blog.djhaskin.com/blog/why-i-chose-common-lisp/

by djha-skin

1/12/2025 at 6:10:16 AM

SBCL is a great choice! It's a surprisingly dynamic system (so are other CL implementations).

A while ago, I did some private work for someone, using SBCL, and sent her the native binary I built, then forgot about the whole thing.

The client came back with some new requirements much later, when the project was concluded, and the source code was already lost by that time.

I vaguely remembered how I did things, so I spawned a REPL from the old binary, went into the relevant CL package, wrote a new function that overrides the old behavior, and the client's problem was solved.

I did all those without the original source code. It was a small thing to fix, but I can't imagine making the same fix so swiftly with any other tech stack, when the source code is lost. I was deeply impressed.

by agentkilo

1/12/2025 at 8:25:28 AM

That's pretty cool, but also, get version control

by chikere232

1/12/2025 at 9:09:38 AM

Version control won't help if the repo itself has been lost to the sands of time

by pizza

1/12/2025 at 9:19:39 AM

Very true.

Get backups

by chikere232

1/12/2025 at 9:45:13 AM

Which the client might be responsible for because the contractor might not be allowed to retain the IP

by wodenokoto

1/12/2025 at 11:59:07 AM

You're "allowed". Just keep it to yourself.

by crispyambulance

1/12/2025 at 3:16:53 PM

You often will not be, explicitly by contract. Honestly in this case it’s easier to keep things clean.

by ska

1/12/2025 at 10:45:15 PM

If you do some work for someone one and decide to keep the source you wrote, so you can review it later in the privacy of your own thoughts, the only way you can get "caught" is if you release it some way that's recognizable.

by crispyambulance

1/13/2025 at 12:12:19 AM

I wouldn't want to hire anyone that thought like this, as it demonstrates a lack of morality and willingness to adhere to not just an informal agreement, but a legal contract that could expose me to liability or IP theft.

by throw10920

1/13/2025 at 11:12:43 PM

If that's what you want to do, why would you ever sign a contract saying you won't do it?

by ska

1/13/2025 at 11:19:46 PM

If the work is interesting and well-compensated, sure, I would sign that contract.

I will also keep the source I write and, if I feel like it, take a look at it years later and no one will know except me. BFD!

by crispyambulance

1/12/2025 at 12:26:42 PM

Then don’t lose your repo xD

by huijzer

1/12/2025 at 11:02:13 PM

Something something hindsight 20/20 etc etc ;-)

by gigatexal

1/12/2025 at 12:06:35 PM

It has been ages since I worked with Common Lisp, so I wonder: Would it be possible / make sense to have version control into the lisp image?

by harperlee

1/12/2025 at 1:58:15 PM

This is basically how Smalltalks work. In addition to the application, an image will generally include a development environment and all the sources to your application. I think Lisp machine Lisps were a lot closer to this too.

by arnsholt

1/12/2025 at 3:23:48 PM

If you dig the old Xerox docs, some of them refer to Lisp as inspiration.

Also the Mesa / Cedar had a similar approach, but based on dynamic libraries, which Niklaus Wirth took great advantage on how Oberon and derived systems worked.

Incidentally, due to Rob Pikes admiration for Oberon, not only had Inferno the ACME editor from Plan 9, already influenced by how Oberon worked, the whole Limbo experience on Inferno is quite similar as well.

Unfortunately we still lack this kind of full stack OS/REPL experience on modern systems.

by pjmlp

1/12/2025 at 4:48:24 PM

I worked on a system implemented in Smalltalk for a few years, and the truly integrated development process possible in a ST is a high I've been chasing ever since. And this was in a setting that had so many things going against it: I started working on it in 2016, and the last update of the runtime environment was from '99. We had a custom HTTP client, and home-brew bindings to OpenSSL that I cooked up with some mad science Python that parsed C headers to generate Smalltalk code. I even had to fix a bug where Winsock fds rolled over if you opened more than 8k sockets, because the runtime FFI bindings assumed a 16 bit wide return value (I assume the code dates back to the Win 3.11 days).

By all rights, it should have been _awful_. But in reality we were able to iterate quickly and actually make stuff, because the technical foundations of the system were rock solid, the team was good, and because the truly integrated Smalltalk development enviroment enables a super-tight development cycle. A joke I have with a former colleague from those days is how all modern languages are still fundamentally no different from the punch card days: You take your sources off to the batch processing center, and the results come out at the other end, while Smalltalk is future techonology from the 80s.

by arnsholt

1/12/2025 at 6:39:19 PM

Yeah we get glimpses of it across JVM, .NET, PowerShell, Fish and so on, but hardly as it used to be.

We do have Pharo, Allegro and such, but their spotlight opportunity is gone.

by pjmlp

1/13/2025 at 3:09:56 AM

> We do have Pharo, Allegro and such, but their spotlight opportunity is gone.

Do you think the paradigm is a dead end?

by andsoitis

1/13/2025 at 8:15:15 AM

In the world of commercial software, sadly yes, compare the idea of Dynabooks with the tablets that we actually got.

by pjmlp

1/12/2025 at 12:34:41 PM

Possible: yes. Lisp image can hold arbitrary data, including source code, versions, etc. Specifically, arbitrary data can be attached to symbols.

Make sense: no, unless you have very special requirements. It would be very different from common practice. Images are still much more fragile than files outside, they are not designed to last across implementation releases.

(Note: some implementations might hold full code of every function in memory, that's not unreasonable.)

by killerstorm

1/12/2025 at 12:17:19 PM

That has been done in the past and was never widely supported. But the landscape is now slightly different. One approach might be to use ASDF (the most popular systems management tool), which then would need to be upgraded to use versions (and ideally have it integrated into a repository mechanism -> Git or similar... Also what are versions in a decentralized world?). ASDF operations then would need to be able deal with version numbers.

A Lisp image would then know/track which versions of what code it has loaded/compiled/... Version information would be stored with the other source files.

by lispm

1/12/2025 at 12:24:42 PM

> That has been done in the past

Could you share some examples of how the old systems did this?

by tiberious726

1/12/2025 at 12:48:39 PM

Can't say what and Interlisp did, but the MIT Lisp Machine and here the commercial variant Genera.

Files are versioned. The Lisp machine file system has versions (same for DEC VMS and a few other file systems). Nowadays the file version is attached to the name&type. Thus editing a file and saving it creates a new file with the same name&type and an updated version number. I can edit/load/compile/open/... files by specifying its version number. If there is no version number specified, the newest file version is used.

A site shared a namespace server with system registry and several file servers.

Code, documentation, etc. is defined as a system, similar to what ASDF does. A system has major and minor version numbers and other attributes (like being experimental or being released). Each time one does a full compile on a system, its major version gets updated and it tracks which file versions it used for that compilation. Whenever one creates a patch (a change of the sources) to a system, the minor version gets updated. After 12 full compiles and 30 patches to the latest version we have system FOOBAR 12.30. This data is recorded in the system directory, thus outside of an image (called a World in Genera) in the file system.

Now I can use that system FOOBAR in another Lisp and "Load System FOOBAR :version Newest" -> This will load system FOOBAR 12.30 into its runtime. Then new patches may appear in the system. I can then in a Lisp say "Load Patches FOOBAR" and it will look into the system directory for new patches to the current loaded major version and load those patches one by one. This changes the running Lisp. It then knows that it has loaded, say, FOOBAR 12.45, what files it has loaded and in which files the respective code (functions, ...) are located.

If I want to ship a system to the customer or someone else, I might tag it as released and create a distribution (with sources, documentation or not). The distribution is a file (also possibly a tape, a bunch of floppy disks, a CDROM, or similar). A distribution can contain one or more systems and its files (in several versions). On another Lisp I can later restore the distribution or parts of it. The restored systems then can be loaded for a specific version. For example I can load a released system version and then load patches for it.

A saved image knows which versions of what systems it includes. It also knows which functions sources are where. It may also have corresponding documentation versions loaded.

Later a source versioning system (called VC) was added, but I haven't used that.

by lispm

1/13/2025 at 9:23:59 AM

It's not a lisp, but Unison (https://www.unison-lang.org/) integrates editor, version control, runtime with content addressed functions

It's pretty cool, and also an obviously terrible idea as you leave behind all standard tooling

by chikere232

1/12/2025 at 2:05:02 PM

Agree, but I think in this case would not help. It was not that a version was lost, but all. Had they had VC, probably the repo would have been deleted.

by f1shy

1/12/2025 at 1:54:55 PM

You don’t deliver source code with the binary at the end of the project?

by munchler

1/12/2025 at 9:07:26 PM

Many don't.

by coldtea

1/12/2025 at 11:45:30 AM

This is something I really like about Common Lisp, but after ~30 years of progress, I am a bit disappointed with improvements in the field of interactive development.

The process you describe is possible in JavaScript and many other languages as well. Updating a JAR is trivial, but doing it in a running system is uncomfortable.

The first thing to start with is versioning at the function, class, package, or module level. Combine that with versioning of data, and you've got my interest :)

by smokel

1/12/2025 at 3:24:48 PM

JRebel, for those willing to pay.

by pjmlp

1/13/2025 at 5:53:08 AM

When will the next standard of Common Lisp be released ? 1994 is really showing is age.

by lenkite

1/12/2025 at 6:08:43 AM

Looks like vim-slime is essential to how you work with CL + vim. I've only used vim for not even 2 years, and came across vim-slime 6 months ago when working in ruby and wanting to quickly 'send' code from editor (neovim) to rails console. 2 months ago I launched a startup and for hours every day had to swat/fix repercussions of bugs that weren't apparent pre-launch (as well as doing via the console things users needed but weren't able to do because the feature to do it hadn't been built yet). It was daunting. I don't know how I'd have managed without vim + vim-slime. Probably a lot of copy/pasting from vscode. Vim + vim-slime was at least a 2x productivity improvement, and >2x increase in developer happiness.

Another huge benefit of vim and vim-slime is it is immediately valuable when you use/learn any new language. So long as the language has a REPL/console/interpreter that can be opened from the terminal or terminal emulator in any form (e.g. CL, ruby, python, bash etc etc etc) then vim + vim-slime will be a brilliant ~IDE. (Possibly the only thing I haven't been able to do but wanted to is 'send' code from neovim to the javascript console in chrome, which would be pretty awesome!)

A side note: I found doom-emacs very similar to vim, only needed ~10 or so new keyboard shortcuts to be productive in emacs. (I still much prefer vim, but I'm not so down on emacs).

by nomilk

1/12/2025 at 6:19:14 AM

>Looks like vim-slime is essential to how you work with CL

slime has some issues for me (obviously not OP) and I am not convinced lisp and vim are a good pair. lem is getting pretty good and improving by the day, find it much better to work with than vim when it comes to lisp and vim is my primary editor.

https://github.com/lem-project/lem

by ofalkaed

1/12/2025 at 9:23:49 AM

I have been using Clojure and before that Racket using only vim and vim-surround for almost a decade now.

I am sure I have left some productivity on the table not investing in workflows like cider etc but I have gotten a decent workflow using just vanilla tmux, a repl pane and vim-surround

The % matcher in vim does so much heavy lifting, I've never felt limited by a lack of slurp and barf

I actually wrote my own tiny plugin to send snippets to the repl using nc and I'm still happy enough tearing the clojure repl up and down and copying stuff in by hand because dealing with repl state can be pain. Even though I have at times had repls open for months, there is a freedom in just tearing it all down and up again.

Clojure itself has plenty of functions to load in files or snippets to help as well

by djtango

1/12/2025 at 4:07:02 PM

> I don't know how I'd have managed without vim + vim-slime.

This is interesting -- I've worked with people who swear by common lisp, emacs, and SLIME.

I'm happiest with ruby and vim, but I have not tried vim-slime (nor even heard of it before, so thank you!).

But FWIW, my strategy for running larger bits of ad hoc code on the ruby/rails console is to:

  1. Add the code to a persistent local file (e.g. "ops_console_tools.rb")
  2. scp the file up to the target machine where I am running the irb/pry console
  3. In the console, run `load '/PATH/TO/ops_console_tools.rb'`
  4. Run the new code: `Ops::User::CustomReport.run(90.days.ago..)`
To keep things a bit more sane, all of the ad hoc ruby code is in modules, e.g. `Ops::User`.

And it helps to include some code to clear constant definitions which would otherwise complain to STDERR if you update and reload the file multiple times.

None of this is as awesome as SLIME of course, but it's pretty tolerable with a bit of readline-style up-arrow and command-history conveniences.

Disclaimer: Of course, running ad hoc code in prod is frowned upon. But we're extolling the virtues of CL in this thread, so I'll confess to breaking best practices in environments where it's permissible! Also this process gives you syntax highlighting while editing without requiring config on target host, and you can include the file in version control for greater formality.

by quesera

1/13/2025 at 5:47:30 AM

I replaced a similar workflow with SLIME-style `eval-defun` by just running the remote Ruby console within emacs, using inf-ruby. Combined with robe, you get code intelligence for free, but without the heavy and error-prone static indexing of Solargraph or Ruby-LSP.

by pritambaral

1/12/2025 at 6:26:23 AM

Yep, I'm using the `slimv` plugin for vim and the `swank` server in a running `sbcl` instance in a second terminal tab. Since I'm on macOS, I could build a keyboard shortcut in vim that automates opening the 2nd terminal tab with the “Lisp machine + swank” when I say “connect” in vim. slimv/swank practically make vim an IDE for Lisp.

by tempodox

1/12/2025 at 3:09:26 PM

How do you learn vim-slime? I have used vim before, so I have basic skills there, but I get lost and run out of time when I try to figure out how the slime model works and how to create a lisp project.

Is there a tutorial you followed or a video you found useful? What was your starting fund of knowledge?

by ferfumarma

1/12/2025 at 10:37:08 PM

Great question - it's shocking easy to learn. Just three steps 1. Install (via vim-plug, lazy.nvim, or whatever vim plugin manager you're using), 2. configure it. Depending on your terminal the instructions are a little different, but it should only take a few moments due to the brilliant instructions found here: https://github.com/jpalardy/vim-slime/tree/main?tab=readme-o... I use kitty so I add two lines to kitty.conf and it's all ready to go. But it will depend on your terminal/terminal emulator. The instructions in the readme should have you covered.

Then 3. use it. This is shockingly easy, open two panes in your terminal with neovim on one side and REPL/interpreter on the other. For example I have neovim with my ruby file on the left pane and a rails console on the right (but on the right could be SBCL, python interpreter, or any other interpreter). In neovim, move the cursor to the line you want to run and press ctrl + c twice in quick succession. It will 'send' that line to the interpreter on the right pane and run that line!

Note: The first time you do this you may be asked which pane vim-slime should 'send' the code to, with the numbers displayed over the panes. For example in kitty I'm usually sending to pane 2, so I press: 2 enter enter. If it was pane 5, I'd press 5 enter enter etc.

If the line of code is immediately proceeded by another line(s) it will run that/those as well (for example, a multi-line Active Record query). It will do the same if there's one or more lines immediately above the current line. This takes a tiny bit of getting used to as you may unintentionally run lines immediately above/below the line for a short while.

That's all there is to it!

A few tips

- As explained above, ctrl + c ctrl + c will run the line under the cursor. But you can also select and run any code you want by selecting it with vim's visual mode and ctrl + c ctrl + c to run that selected code. For example, if you want to run part of a line, select it in visual mode and ctrl + c ctrl + c and it will run! Same for say a few hundred lines of code: select it all in visual mode (e.g. v ctrl + f ctrl + f then j or k to get to the exact line), then ctrl + c ctrl + c will run everything you selected.

- Rails specific: The rails console has a pager set to 'on' by default (this would necessitate back and forth between panes in order to press 'q' to quit out of the pager). So I turn it off by adding one line (IRB.conf[:USE_PAGER] = false) to ~/.vimrc or just .vimrc in the project directory.

Let me know if you have any questions/troubles.

by nomilk

1/12/2025 at 8:37:42 AM

That is a very interesting journey — mine was exactly opposite, after many years with Common Lisp, I moved to Clojure and wouldn't even think of going back. I find it intriguing that the author would want to move in the other direction, especially as concurrency was mentioned (one of the main reasons why I initially looked at Clojure).

I wonder what it was about babashka that didn't work for the author. When I need a quick script with batteries included, I use babashka and it works great.

by jwr

1/12/2025 at 8:46:49 AM

I had already written large, nontrivial apps (linked in article) which required more libraries than babashka was written with, including ones I had written but also others. I therefore needed to run native-image on my own codebase, as it was not runnable from within babashka (at the time? I don't know if it is now).

Running native-image on an already established, not-written-for-it codebase is a nightmare. I just tried again some months ago on the linked code bases. native-image wouldn't budge. Kept getting hung up on I don't even know what, the errors were way too opaque or the app just misbehaved in weird ways.

by djha-skin

1/12/2025 at 9:20:54 AM

Ok, that explains why babashka wasn't suitable. I still wonder, though, about the requirement to have an executable.

I still remember many years of reading comp.lang.lisp, where the #1 complaint of newcomers was that "common lisp cannot produce a native executable". I remember being somewhat amused by this, because apparently nobody expected the same thing from other languages, like, say, Python. But apparently things have changed over the years and now CL implementations can produce bundled executables while Clojure can't — how the tables have turned :-)

by jwr

1/12/2025 at 11:26:54 AM

I think various Lisp implementations have their own way to do it, e.g save-lisp-and-die on SBCL.

But, if what you mean "executable" is "small compact executable like the one build by C/C++/Pascal, without extra Lisp runtime attached", perhaps you better look at something else, well like C.

by anta40

1/12/2025 at 1:58:06 PM

`uiop:dump-image` lets you do it in an implementation independent way.

by shawn_w

1/12/2025 at 12:28:31 PM

You just need to use a lisp implementation that has a tree-shaker if you really care about binary size for since reason

by tiberious726

1/12/2025 at 4:45:06 PM

Chicken Scheme makes very nice, tidy binary executables. "Hello World" is just 27K on Ubuntu.

by whartung

1/12/2025 at 8:42:06 PM

Gerbil scheme gives you the tiny bins and fully static binaries. No need to cargo cult portions of quicklisp with the binaries.

by matrix12

1/12/2025 at 10:32:08 AM

There is already confusion. Things are different and the same words (executable, native, image, ...) mean slightly different things.

In the CL world it is usually relatively easy to create an executable. For example in SBCL I would just run SBCL and then save an image and say that it should be an executable. That's basically it. The resulting executable

* is already native compiled, since SBCL always compiles native -> all code is AOT compiled to machine code

* includes all code and data, thus there is nothing special to do, to change code for it -> the code runs without changes

* includes all the SBCL tools (compiler, repl, disassembler, code loader, ...) thus it can be used to develop with it -> the code can be still "dynamic" for further changes

* it starts fast

Thus I don't need a special VM or special tool to create an executable and/or AOT compiled code. It's built-in in SBCL.

The first drawback: the resulting executable is as large as the original SBCL was plus any additional code.

But for many use cases that's what we want: a fast starting Lisp, which includes everything precompiled.

Now it gets messy:

In the real world (TM) things might be more complicated:

* we want the executable to be smaller

* we want to get rid of debug information

* we need to include libraries written in other languages

* we want faster / more efficient execution at runtime

* we need to deliver the Lisp code&data as a shared library

* we need an executable with tuned garbage collector or without GC

* the delivery structure can be more complex (-> macOS application bundles for multiple architectures)

* we want to deliver for platforms which provide restrictions (-> iOS/Apple for example doesn't let us include a native code compiler in the executable, if we want to ship it via the Appstore)

* we want the code&data be delivered for an embedded application

That's in the CL world usually called delivery -> creating an delivered application that can be shipped to the customer (whoever that is).

This was (and is) typically where commercial CL implementations (nowadays Allegro CL and LispWorks) have extensive tooling for. A delivered LispWorks application may start at around 7MB size, depending on the platform. But there are also special capabilities of ECL (Embeddable Common Lisp). Additionally there were (and still are) specialized CL implementations, embedded in applications or which are used as a special purpose compiler. For example some of the PTC Creo CAD systems use their own CL implementation (based on a ancestor implementation of ECL), run several million lines of Lisp code and expose it to the user as an extension language.

by lispm

1/12/2025 at 10:23:10 PM

> I moved to Clojure and wouldn't even think of going back.

It's always amusing to watch programmers arguing for superiority of their favorite language(s) over others, often bashing language features without clearly understanding their purpose.

And it is especially amusing to watch Lispers trying to argue with each other. "I chose Scheme", "I picked Clojure", "I moved to CL"... etc.

Bruh, I move from one Lisp to another based on my current needs. It's harder for me to choose new shoes than switching between Lisp dialects. Once you learn any Lisp to a sufficient level, the mental overhead between Lisps becomes almost negligible - it feels like practically operating the same language.

Sure, each Lisp is unique and they all have different flavors, but seriously, shouldn't we celebrate the diversity and be happy that we have at least one Lisp for every platform?

@jwr This isn't meant as criticism of your comment. I'm not arguing at all with what you wrote; Clojure is my favorite Lisp flavor as well. I'm just taking a sentence out of context and using it as a cue for my rant - don't be mad, we're cool.

by iLemming

1/12/2025 at 11:31:45 PM

Yes, I think this is perpendicular to my comment. I stopped arguing about language superiority a long time ago, my comments were intended to reflect my own journey only.

by jwr

1/12/2025 at 10:58:00 AM

More than decade ago, I didn't understand an actual value of Lisp, but I remember this song well.

https://www.youtube.com/watch?v=HM1Zb3xmvMc

by Naru41

1/12/2025 at 12:00:24 PM

Every programming language should have a music video!

by crispyambulance

1/12/2025 at 10:40:15 PM

Heh, every function in every Lisp needs its own song (:

Here's one for clojure.core/lazy-cat

https://suno.com/song/d012fa48-d5c1-46f4-8561-9a031cfb8925

Makes me sad that Clojure has mapcat and lazy-cat functions, but they've never made any effort to create mapdog and lazy-dog variants. I firmly believe that is the unique and only factor that has prevented Clojure from becoming a mainstream language at the top of the RedMonk chart.

by iLemming

1/12/2025 at 4:19:44 PM

As a counterpoint to author's use of vim-slime (not to say I don't believe author's commet of "I'm Okay, I Promise," but rather to communicate to others who are facing a similar choice:

I am a lifelong vim user (since elementary school in the early '90s), and I developed common lisp using vim for over a decade. I still use vim for nearly everything, but emacs as my Lisp IDE. Before evil-mode, I used the mouse and menus for 90% of what I did, and it was still an improvement over the best vim had to offer at the time (vim-slime existed back then, but would crash or hang regularly).

Author's vim setup is fairly good, but Emacs/slime is still better. They stopped using emacs because of RSI, but their vim setup defaults to "v a ( C-c C-c" to accomplish something that is "C-c C-c" in emacs/slime. They have altered it to be "v a ( <space> g" which begs the question of "why not remap keys in emacs?"

by aidenn0

1/12/2025 at 6:50:06 AM

I have been working with Clojure for 5+ years now. For CLI applications babashka has worked quite well for us.

Would love to know more about the problems you faced.

In my experience whenever I faced such issues - it has been because I am not using it well.

For CLOS kind of things I have found https://github.com/camsaul/methodical library quite well and the performance is better than default multimethods in core clojure implementation.

by pntripathi9417

1/12/2025 at 5:55:56 AM

> spent long, hard hours banging my head against native-image and it just wasn't working out.

it would be nice to know what exactly isn't working out and what the problems with native-image was.

Coz i think clojure is as close to perfect, imho, as a language can go without selling out.

by chii

1/12/2025 at 6:41:48 AM

Graalvm native image for Clojure is a solved problem. Just add this library to the project and add a flag to native image command line.

https://github.com/clj-easy/graal-build-time

This initializes Clojure classes at build time and it mostly works for pure Clojure code.

Doing complicated things (e.g. depending on native library, etc.) requires some tweaking. For example, a few packages may need to be declared as initialized at build time or run time, depending what they are doing. And any unresolved classes need to be added to reflection-config.json.

All these are easily discoverable if one talks to people in the Clojurian slack channels. Clojure is a small community, so it helps to be part of it, because there are not a lot of open materials on the Web.

by huahaiy

1/12/2025 at 7:55:44 AM

> solved problem

except...

> mostly works

> requires some tweaking

> discoverable if...

I know nothing about Clojure but from your caveats I think I can see why he spent hours banging his head against a wall.

by IshKebab

1/12/2025 at 8:09:09 AM

when engineers say it's a solved problem, they mean it in the same way as a mathematician saying a theorem is trivially proved.

by chii

1/12/2025 at 7:07:11 PM

> theorem is trivially proved

Reminded me Prof. Knuth trolling in "The Art Of Computer Programming" with an exercise for the reader to prove Fermat's Last Theorem. (:

by iLemming

1/12/2025 at 8:46:22 AM

Look at the hoops OP had to jump through to get SBCL working on Windows. I think Graal would compared favourably with that.

by macmac

1/12/2025 at 4:05:08 PM

Probably, but that doesn't mean Graal is good; it just means they're both bad.

Compare it to something like Go or Rust where there are no hoops and they're both well supported on Windows and Mac. I haven't actually used it but I believe Zig has very good cross platform support too.

by IshKebab

1/12/2025 at 7:40:01 PM

if I recall correctly Rust support for windows still has issues, namely there are a number of Windows specific APIs that are either not well supported or aren’t supported at all.

I could be mistaken or recalling outdated information of course, but that is what I remember from the last time I looked into it

by no_wizard

1/12/2025 at 11:23:01 AM

What did you mean? Can't the user just download Portacle and use it?

https://portacle.github.io/

Problem solved.

by anthk

1/12/2025 at 12:16:47 PM

Right at the top of the article, the author outlines the requirement was that it must be usable within vim.

by chii

1/12/2025 at 12:18:08 PM

Not an issue for Common Lisp, you can use whatever you like, but interacting with a REPL gives you superpowers.

by anthk

1/12/2025 at 8:36:47 AM

I actually just dusted off my old Clojure stuff to see if it was a "solved problem", and it isn't.

I grant that it might be described thus if I started out with that stack, but trying to retrofit an older code base with it is, I have found, next to impossible. You have to code around the myriad gotchas as you go or you're never going to identify all those landmines going back over it after the fact. The errors and bad behaviors are too difficult to identify, even for the `native-image` tooling.

by djha-skin

1/12/2025 at 7:07:06 PM

No. I have looked at your code. You did not use the mentioned https://github.com/clj-easy/graal-build-time

If you don't do what everybody is doing to solve a problem, then of course it is not a "solved problem" for you.

No, you don't need to code specifically for native-image. What are the landmines that you need to code around? Since you have not successfully compiled native-image by following common practices, you obviously don't know.

by huahaiy

1/13/2025 at 10:38:11 AM

Why do you imagine the OP would push a failed experiment to a publicly available spot? They probably left it sitting in a local branch and went on with their day.

by KingMob

1/13/2025 at 5:35:58 AM

what are you referring to when you say a language can sell out?

by m1n1

1/12/2025 at 3:58:48 PM

I am looking at CL myself, but my needs are more hobby than anything, but I want to convince myself I can find it useful for my own work in certain things (e.g. I want to maybe use Bike to run C# code in an SBCL REPL.)

The feedback loop one gets with it is insanely fast, even faster than Python (certainly there are exceptions even with Python ...) That's a blessing and curse for me - the tighter a feedback loop, the harder for me to get out of a problem I am stuck on. :) But, so far, I felt like I can write a thing and not worry about running it ... type a thing, quickly get it running it in a running REPL loop. If a mistake happens, I can fix the issue right there, instead of just a long stack trace. For what it is worth though, I have been doing this in Emacs for a long time (well, for small functions), but didn't think much of it until now.

by bigpeopleareold

1/13/2025 at 9:54:37 PM

If you are wanting to play with C# in a REPL (although C# has a REPL these days; it's not great but it works), F# could be worth a try. I know the Scheme/ML family split means not everyone who likes CL/Scheme likes the ML family (and vice versa), but F# is a "good one" for what that is worth.

by WorldMaker

1/12/2025 at 7:11:17 AM

Related, Janet: https://janet-lang.org/

I especially like its github readme and the FAQ there, provides a good amount of context about the project: https://github.com/janet-lang/janet

by thih9

1/12/2025 at 10:37:09 AM

It's mentioned in the article:

> If I had heard about Janet when starting this hunt, I might have stopped there and not gone on to CL. Nice syntax, small, fast executables, C FFI, a fun intro book. It checks all my boxes.

by draven

1/12/2025 at 2:40:39 PM

It's great, but I found the library ecosystem lacking for my particular use cases . The joy web framework, in particular, seems to have stalled in time.

by rcarmo

1/12/2025 at 10:03:32 AM

Ah, it's this time of the year when we get to fantasize about cool platforms and languages before succumbing back to python, typescript or feeding the relentless AI monster in a major cloud provider.

by darthrupert

1/12/2025 at 1:17:31 PM

Because we are not allowed to program in another language that 'most' programmers can't understand immediately.

We are cursed to use the lowest common denominator of choices of programming.

by worthless-trash

1/13/2025 at 3:40:17 AM

> Because we are not allowed to program in another language that 'most' programmers can't understand immediately

If everyone in a code base wrote in a different programming language, the code base would suck.

by andsoitis

1/14/2025 at 3:15:39 AM

I have heard that LLM's transpile between languages perfectly. They'll be able to fix problems like this.

However on a serious note, "the industry" fears even writing the entire codebase in a 'non common' language because of it, let alone your strawman idea of multiple languages.

by worthless-trash

1/12/2025 at 8:16:30 PM

Typescript is great! Except the JavaScript below it which is terrible, but the static analysis and constraints I can express in typescript are amazing.

It’s actually surprising that there’s no typing discussion in this thread.

by baq

1/12/2025 at 5:58:27 AM

I don't understand the "Requirements Met" section, that reasoning applies to almost any programming language. You chose Common Lisp because there's a JSON library?

by stevebmark

1/12/2025 at 7:31:13 AM

A lot of these intermediary languages are not trivial to parse safely and are a vector for exploits. It's not something you can really do on your own unless you're just supporting a specific subset for your application. Even then, you really need to know what you're doing.

by neuroelectron

1/12/2025 at 9:42:51 AM

There's a section "hunt for new Lisp". It isn't explicitly stated in the requirements maybe because it can be inferred from there that being a Lisp is also one.

by forgotpwd16

1/12/2025 at 8:00:19 AM

Yeah I thought he would go with Rust or Go after seeing those requirements.

Clearly there was another implicit requirement - maybe it had to be a niche language?

by IshKebab

1/12/2025 at 8:28:01 AM

Probably had to be a Lisp, considering the OP was coming from Clojure. Rust and Go fail that (unwritten) requirement.

by weikju

1/12/2025 at 7:14:21 AM

> I wrote this blog post because I noticed that there have been more newcomers on the Common Lisp Discord

Even CL people are using Discord now? People really do seem to love to converge to a single place.

by brabel

1/12/2025 at 11:11:21 AM

My go-to community for Common Lisp has always been and likely always be the #commonlisp channel on Libera IRC. The community formerly existed on the #lisp channel (if I remember correctly) of Freenode for several decades. It migrated to Libera after a controversial change in Freenode management in May 2021. Webchat link for #commonlisp: https://web.libera.chat/#commonlisp

Further, the on-topic #commonlisp channel on Libera comes with a cozy off-topic channel named #lispcafe for general chit-chat about any imaginable topic. Webchat link for #lispcafe: https://web.libera.chat/#lispcafe

by susam

1/12/2025 at 7:26:39 PM

thanks for those links.

by fuzztester

1/12/2025 at 11:33:51 AM

> Even CL people are using Discord now? People really do seem to love to converge to a single place.

Except Discord servers cannot be described as "a single place" even, as they're all isolated from each other.

Instead of spread out across multiple open IRC networks/channels, developer communities converged into silo'd, closed/proprietary Discord servers. It's a shame.

by diggan

1/12/2025 at 7:21:07 AM

Unfortunately as all the interesting stuff disappears when the server closes. I know it can be remedied, but unfortunately it's not standard. Especially for CL this is crappy as a lot of things are still valid and working 10 years from now but the discord server is long gone.

by anonzzzies

1/12/2025 at 10:51:00 AM

#lisp and it's offtopic channel #lispcafe at irc://libera.chat are far better.

Also, comp.list at Usenet.

by anthk

1/12/2025 at 6:59:21 PM

Did you mean comp.lang.lisp ?

Because that's the usual convention, like comp.lang.c, .python, etc.

by fuzztester

1/13/2025 at 6:03:52 PM

yes, I made a typo.

by anthk

1/12/2025 at 10:12:52 AM

The author says they went about learning CL the wrong way. I wonder if there is a standard "community approved" way of learning the language?

by quibono

1/12/2025 at 4:09:31 PM

Not standard, but hopefully worth mentioning: the thing that's clicked best for me is the docs on https://ciel-lang.org/ ("batteries included" Common Lisp image). The examples for how to use it's curated libraries matches how I try to integrate a new language into my toolbox.

It hit the front page a while ago too: https://news.ycombinator.com/item?id=41401415

by wwfn

1/12/2025 at 6:16:05 PM

Gentle Introduction to Symbolic Computation is a great book, I learned a lot. The 1990 version available for free below has aged well but you need to look elsewhere for getting setup with emacs and slime or whatever environment you want.

https://www.cs.cmu.edu/~dst/LispBook/

by lispshillin291

1/12/2025 at 9:08:26 AM

With the great tooling Common Lisp commercial systems inherit from Lisp Machine and Interlisp-D days, it is kind of sad seeing vim being the option.

Also unless we're about Allegro or LispWorks with their own additions, the Java ecosystem tends to have more choice of mature libraries, I think ASDF isn't kind of spoiled by choice as Maven Central.

But to each their own.

by pjmlp

1/12/2025 at 10:53:18 AM

There's Emacs and Slime too OFC. Also, Quicklisp/Ultralisp aren't ASDF, you are pretty outdated...

https://www.quicklisp.org/beta/

https://ultralisp.org/

by anthk

1/12/2025 at 1:59:02 PM

As someone that knows Emacs since XEmacs glory days, I am surely not outdated regarding Emacs, Slime, and what they still miss from commercial Common Lisp experience.

As for Quicklisp, I may not be up to the latest and greatest, yet I doubt they are at the same level as Maven Central.

by pjmlp

1/12/2025 at 6:11:14 AM

I went on a similar journey a couple of years ago and ended up on Gerbil Scheme instead.

by packetlost

1/12/2025 at 8:43:35 PM

Great choice. Fully static binaries are a win.

by matrix12

1/12/2025 at 3:35:38 PM

Care to explain why?

by tasuki

1/13/2025 at 12:17:28 AM

Fast, Scheme is more to my tastes, a real module system, real multicore support, (syntax-rules).

by packetlost

1/12/2025 at 11:46:08 AM

Common Lisp is a great choice for many purposes. (And, if you're doing a startup, a fringe language like CL is a good way to find and attract some of the best hackers, and avoid all the Leetcode grunts.)

Just comments on the Scheme/Racket parts...

> I looked at Scheme, but that community seemed to still be fractured over the r6rs/r7rs mess.

Things were fractured before R6RS, with very little portable ecosystem code, and then R6RS didn't solve that, but AFAIK, people got back up on that horse, started over, and have been embracing R7RS.

> Also, there wasn't a big enough ecosystem to suit my liking.

There's a reasonably-sized ecosystem, but three things:

1. Unless things have changed recently, much of the good stuff is still in the package system for a particular implementation (like Racket, "https://pkgs.racket-lang.org/", or Chicken, "http://eggs.call-cc.org/5/").

2. It's nothing the size of Python or JavaScript.

3. Don't believe any claims of "batteries included"; you often have to roll your own basic packages for real-world work. (But this can actually be a blessing, even for startups that have to move fast, depending on what you have to do, and how capable you're willing to rise to be.)

> I'd already tried Racket in school and didn't like it. The runtime was a bit slow and bloated for my tastes.

Although CS professors are some the greatest friends of Scheme (having designed and made much of it), CS professors can also be the worst enemies for real world use of Scheme.

Before Racket, most people who had heard of Scheme knew it only from school, in problem set homework for the dense SICP course, or from whatever pet intro CS textbook their professor wrote. That's a good way to never want to try Scheme again. (And it got worse as many CS departments became optimized Leetcode->FAANG hiring funnels.) Then people never saw Scheme used, nor even described by, real-world programmers, for real-world things.

So Racket (PLT Scheme) comes along, and half of the handful of people thinking of Scheme as a language for real things gravitate to Racket, because they are doing some real-world things. And overall it's one of the best programming languages out there.

But still, although the Racket CS professors include some great programmers, Racket is determined by CS professors, who do PL and CSE research, and write and teach textbooks. So, Racket's use in intro CS classes seems to perpetuate the tradition of CS professors ensuring that students will never again want to touch Scheme after they get a passing grade for the class.

by neilv

1/12/2025 at 4:59:21 PM

Racket's Chez Scheme backend, which is the default for several years is faster than python and ruby, and raco distribute gets you a smallish package with just your program, portable to the major OSes. Smallish = 40mb, which is probably comparable to other dynamic lands that don't come preinstalled.

I find the "I tried it years ago and it wasn't as nice then, so I'm not gonna look at it again" attitude quote off-putting. It's the same reason Java still gets so much hate after over a decade since Java 8.

I agree that CL and Closure probably has more real world shipped products. However, if you are considering a newer and smaller ecosystem like Janet... you owe it to yourself to look at Racket with fresh eyes.

by nsm

1/13/2025 at 3:21:57 AM

We're 12 years since the release of r7rs-small and there's still no standard library as r7rs-large is essentially MIA. I remember seeing that they'd done a preliminary release of just one small part of r7rs-large. It was existing functionality and basically copied what already existed, but still somehow took over a decade.

This is important give the history. R6rs was an attempt at an actually-usable scheme spec. R5rs isn't usable as described because there's way too much undefined stuff to actually get up and running in a semi-portable way. This problem exists BEFORE discussing the SRFIs which are quasi-standards except that every implementation supports a different subset and they aren't documented outside of the spec documents which themselves generally aren't fully specified.

Scheme the standard killed itself and Racket survives because it completely avoided the illusion of compatibility entirely.

by hajile

1/12/2025 at 11:14:41 PM

Oh man — this has come the closest to getting me to want to really learn lisp — especially because the author is an avid fan of vim

by gigatexal

1/13/2025 at 9:59:52 PM

The semester of my life that I coded everything in Common Lisp I was using vim to do it. Vim didn't make anything harder and some macros I had at the time and some extensions like vim-slime did everything I needed them to do just fine. Emacs has the whole "Emacs is also a Lisp" thing that gives it a lot of prominence as the editor/IDE of choice for most styles of Lisp, but some of that is just marketing.

by WorldMaker

1/17/2025 at 6:08:32 AM

Hey same for 25 years of my life, and counting.

by kazinator

1/14/2025 at 3:57:06 AM

I've been working with Lisp for a quarter century now. Always with Vim.

My TXR Lisp comes with Vim support: a pair of syntax files and also a tags generator.

by kazinator

1/12/2025 at 7:16:34 AM

To the extent that Julia is a Lisp (which requires some squinting and handwaving), I wonder how it stacks up against these requirements. With my limited knowledge:

1. Standalone Executables: The biggest current obstacle right away! But I believe this (as in compilation to standalone, small executables) is coming with the next version (Julia 1.12) in an early form, so maybe stabilized and reliable within this year? There does seem to be a lot of momentum in this direction.

2. Vim Workflow: vim-slime works well to my knowledge, and the overall support (eg. treesitter, LSP, etc.) is pretty good, even if VS Code is the "main" supported editor.

3. Windows/Mac/Linux Support: mostly Tier 1 support [https://julialang.org/downloads/#supported_platforms]

4. Larger Imperative Ecosystem: FFI with both C and Python are pretty standard and commonly used.

5. Runtime Speed: Crazy fast as well

6. Multithreading: Base language support is already pretty good, and there's OhMyThreads.jl [1] and data chunking libraries and many other supporting libraries around multithreading.

7. Strong Community: I'd expect Julia and CL communities to be on the same order of magnitude? Complete assumption though, in both directions. Web presence is mostly on the Discourse [2] and Slack, and the JuliaCons are pretty well attended.

8. Ecosystem: Since package management is mentioned, I'll shout out the built-in Pkg package manager, the seamless virtual environment support, and the generally quite good versioning in the ecosystem, all of which add up to a really good experience. As for particular libraries, JSON is the only one I know the answer to: JSON3.jl is a solid, standard choice. I don't know if SQLite.jl [3] would be the recommended option for SQLite or something else, HTTP.jl does the job for HTTP requests but I believe isn't particularly fast or sophisticated, and I could believe there's a subcommunity within Julia that uses "functional data structures" but I wouldn't even know where to look. But, for the ex-Clojurian, may I present Transducers.jl [4] as worth a look?

[1] https://juliafolds2.github.io/OhMyThreads.jl/stable/ [2] https://discourse.julialang.org/ [3] https://github.com/JuliaDatabases/SQLite.jl [4] https://github.com/JuliaFolds2/Transducers.jl

by sundarurfriend

1/12/2025 at 1:57:44 PM

> 6. Multithreading: Base language support is already pretty good, and there's OhMyThreads.jl [1] and data chunking libraries and many other supporting libraries around multithreading.

Agree on the rest, but multithreading in Julia is a let down.

The manual (https://docs.julialang.org/en/v1/manual/parallel-computing/) claims it's composable, but that's only true if you stay within Julia with the paradigm of Tasks. As soon as you interface with C/C++, you get a SegFault, as the Julia runtime expects to adopt [1] all threads calling into it. This is not always viable.

Julia should offer the option of C-style pthreads (or the Windows equivalent) and let others build abstractions on top of them.

[1] And that option was only added recently.

by Archit3ch

1/12/2025 at 7:08:13 PM

I haven't had to work on the intersection between FFI and multithreading, so I can't comment on that. I was more commenting on the ease-of-use of normal multithreading within a Julia program, and the availability of primitives around it. I've found it much easier to take an existing working program and parallelize it in Julia, than in most other languages I've worked with. (Granted, a lot of this is simply that Julia is a newer language and hence gets to design these into the language from the get-go instead of adding the parts piecemeal over years.)

by sundarurfriend

1/12/2025 at 8:47:04 PM

> I've found it much easier to take an existing working program and parallelize it in Julia, than in most other languages I've worked with.

Unfortunately, this isn't possible when interfacing with proprietary, closed-source binaries. Especially when the C FFI is defined by standard, makes no mention of threading, and each implementation has different quirks.

by Archit3ch

1/12/2025 at 2:44:42 PM

Multithreading seems to work just fine with OpenBlas. It is also sometimes possible to wrap the underlying state machines from C/C++ code and then making it multithreaded in the Julia side.

by JanisErdmanis

1/12/2025 at 3:13:14 PM

None of that contradicts what I wrote. Note that it's calling into Julia from C/C++ that presents problems, the opposite is fine.

by Archit3ch

1/12/2025 at 9:54:50 AM

Last I checked, Julia actually compiled rather slowly, making development a lot less fluent than a Lisp.

Beyond that, wrapping C code from Julia is neither nicer nor worse than from CL. Wrapping C code is basically done everywhere except for a few outlier languages (Go comes to mind. It IS possible, but it means using cgo, which is its own world).

I liked Julia well enough, but the compile times were slow enough to be painful for me. All the best though to Julia :)

by pseudony

1/12/2025 at 2:59:28 PM

> Wrapping C code is basically done everywhere except for a few outlier languages

Agreed, I only included this because the author mentioned it explicitly as a requirement. From a "allows plugging into some other, large-community imperative language, like Clojure does with Java" perspective - in terms of library access - the combination of having well-polished interfaces to both C and Python is pretty powerful though.

> the compile times were slow enough to be painful for me

I think this, and the developer experience in general (eg. linting, IDE support, etc.), has been the biggest reason the excitement for Julia dampened over time, despite it being a wonderful language in theory. It's been getting better, from "painful" to just "somewhat annoying" for me, but not quickly enough to turn it around (IMHO).

by sundarurfriend

1/12/2025 at 10:04:31 AM

food for thought and feel free to chime-in: https://gist.github.com/vindarel/15f4021baad4d22d334cb5ce2be... Common Lisp VS Julia

by vindarel

1/12/2025 at 6:52:37 PM

The "feedback and answer" below the gist already covers a bunch of things I wanted to mention. So I'll skip those and only talk about the rest:

> You can't make it a CLI script, because it compiles the whole code WITH dependencies every time

The "with dependencies" part is mostly untrue nowadays, with constantly better pre-compiled caches for dependencies with every release. The overall issue of compile times getting in the way of interactive development still has some truth to it, but much less than the comment implies.

> https://viralinstruction.com/posts/badjulia/

1. The subheadings in the ToC are mostly based on comparisons with the best-in-class: for eg. "Julia can't easily integrate into other languages [compared to C]", "Weak static analysis [compared to Rust]".

2. Seeing this actually gave me hope about Julia's progress, based on how many of these issues have been largely mitigated or have been actively worked on in the last three years since the post.

3. As a side note, the author of the post is still an active user of and contributor to Julia, so I think this kinda falls under the "There are only two kinds of languages: the ones people complain about and the ones nobody uses" banner. As in, the complaints are there because they like and actively use the language enough to want it to be the best in every way.

> Even though Julia 1.6 was a lot faster than 1.5, it still took too long.

I agree - I think pre-1.9 Julia experience sucked, and overselling the language in that period hurt its reception a lot. (I've mentioned elsewhere in the thread that the developer experience is still one of the weaker points of Julia.)

> (in CL a hello world weighs ±20MB):

In Julia 1.12, with the experimental --trim feature, a hello world is <1MB. Still too early to tell how that'll translate to real programs though.

> false ? 1 : 2 : 3 : 4

This is hilarious and awful at the same time. There's no beating CL in this - I've learnt that every language with syntax unfortunately develops "wat"s like this over time when well-intended syntax features interact.

> A few months ago, I tried to write a program that should receive UDP packets over IPv6 multicast.

> It didn't work. I never figured it out. This works in Java and Python.

> This might be unfair or untrue, but I get the feeling that it doesn't work because no one has seriously tried to use the language this way.

I don't think it's either of those: it seems like networking was and remains a weak area in Julia. For eg., though the language itself is blazingly fast, there have been a bunch of reports about how HTTP traffic performance is several time slower than ostensibly slower languages like Ruby. The reason is probably what the quote says too, there just isn't as much of a userbase or demand for this side of things.

> my packages seem to really like breaking when I try to load them about once a month

There's no source for this one, and no info on what "breaking" means or what the packages do, so I can only say this isn't a common experience. It's very easy to "pin" dependencies to preserve a reproducible state of dependencies and replicate it as well, which is greatly useful in a language used for science.

> I migrated from Lisp to Julia for the ecosystem. It hasn't been worth it from my point of view. I'll migrate back to Lisp eventually. [on a post] about lisp-stats

I'm not very surprised, given the lisp-stats context - it seems to be a common assumption/misconception, because Julia gets compared to Python and R often, that it's a data science and stats focused language. It's great for greenfield stats work, pleasant in many ways compared to those two, but the ecosystem is not particularly focused specifically on it. I'd suggest choosing Julia for the ecosystem if you're doing science science - quantum computing, diffeq modeling, numerical optimization, many others - but on the data science side, what Julia offers is consistent syntax, performance without C reliance, while retaining niceties like DataFrames and Tidier that other languages offer.

by sundarurfriend

1/12/2025 at 6:44:09 AM

If your looking to write CLI utilities in Clojure babashka really is awesome. It doesn't meet the author's standalone binary requirement, but it's got great startup time and comes batteries included with all sorts of helpful tools.

by Volundr

1/12/2025 at 7:22:42 PM

There's also nbb for Node. the REPL is instantaneous, it's almost annoying - sometimes instead of fixing some lopsided state in the REPL, I'd gravitate towards restarting it. And of course there are tons of libraries, well, some of them may not be of the highest grade, but for every mediocre choice there's usually multiple excellent ones. Also it takes some time to get used to everything being async, nevertheless, nbb is a great option for scripts involving e.g., web-scraping or testing with Playwright.

by iLemming

1/13/2025 at 4:25:00 AM

Curious if you didn't look at F#? Seems like it would've been a good fit (perhaps except for the Vim support?)

by rubenvanwyk

1/13/2025 at 10:20:13 PM

I'd imagine Vim support is pretty good now for F# and getting better as F# continues to see its LSP improved. (I haven't tried it recently as VS Code is often "good enough" for most of my F# needs, but given it's the same LSP at this point, that seems indicative.)

by WorldMaker

1/14/2025 at 8:44:23 AM

What about free pascal compiler and Lazarus IDE?

by ags1905

1/12/2025 at 10:09:23 PM

Cos shipping things is not a concern

by xiaodai

1/12/2025 at 2:20:42 PM

Common Lisp is great until it isn’t.

by Horffupolde

1/12/2025 at 2:24:00 PM

And then you grab a macro, extend it and it's great again ;)

by Guthur

1/12/2025 at 5:39:54 PM

Does anyone use Clojure CLR? How is the startup time for that?

by joshlemer

1/13/2025 at 10:41:58 AM

Probably similar to JVM clojure.

The .net VM is similar to the JVM in perf, but iirc, the clj startup time is more dominated by Clojure itself (like var initialization).

by KingMob

1/14/2025 at 12:21:43 AM

Oh yes I get that, but wasn't sure if there was some kind of better support for AOT compilation in the CLR which could do Clojure startup at build time or something.

by joshlemer

1/12/2025 at 7:51:51 AM

[dead]

by oldpersonintx

1/12/2025 at 6:37:31 AM

tl;dr: OP was using a Lisp and they were looking for a different Lisp.

Probably the only reason why anyone would ever pick Common Lisp for a new project in 2025.

by billmcneale

1/12/2025 at 6:46:59 AM

Why? Not everyone is resume grifting. It is fast, solid and has excellent developer workflows. Lot of stable (oh no, no updates for 10 years because it just works!) libraries. With CLOG it is a nice secret weapon with people wondering how you managed to move that fast. At least in our experience but we make products so we don't have to explain what it is made of or why.

by anonzzzies

1/12/2025 at 2:46:33 PM

> no updates for 10 years because it just works!

Maybe I’m crazy, but that is what I like from Lisp

by f1shy

1/12/2025 at 3:09:54 PM

yep, same.

by anonzzzies

1/12/2025 at 10:41:45 AM

Lmao, my thoughts exactly.

Q: why I chose common lisp

A: I was looking for a lisp to begin with

This is almost like a satire. But I've found it rather funny. It presents question and provides an answer which is contradictory at first but still makes sense.

by bmacho

1/12/2025 at 6:00:17 PM

> Q: why I chose common lisp

> A: I was looking for a lisp to begin with

> This is almost like a satire

How? It's no different than "Why I chose Arch Linux? I was looking for a Linux to begin with."

To even think that's satire is to completely miss the point.

by BoiledCabbage

1/12/2025 at 10:28:30 PM

In their defense I can understand going into this article expecting it to be "why I chose Common Lisp [over other programming languages]", rather than "why I chose Common Lisp [over other Lisp dialects]" -- I think most of the HN audience are not people who are often using a Lisp dialect, so their question going in would be "why not use the programming languages I'm more familiar with?"

Meanwhile, "why I chose Arch Linux" is more likely to be interpreted as "...over other types of Linux" because most HN people are already familiar with the decision of "which Linux distro will I use?" But if you gave that headline to someone who doesn't have much familiarity with Linux they'd probably expect the article to address why they chose it over Windows or Mac.

(I don't think "why I chose Common Lisp over other Lisp dialects" is an absurd premise for an article like the person you're replying to does, but I can at least kinda see where they're coming from)

by joks

1/12/2025 at 8:12:46 AM

[flagged]

by linkerdoo

1/12/2025 at 9:30:45 AM

Win what?

by mseepgood

1/12/2025 at 8:44:36 AM

[flagged]

by linkerdoo

1/12/2025 at 8:50:56 AM

You'll lose first.

by dokyun

1/12/2025 at 2:37:14 PM

Jank

by transfire

1/12/2025 at 8:23:18 AM

He cannot use Emacs and then goes to ... Vim ?!?! Nothing against Vim or Emacs, I love both but they had their time which is long gone. I am using Linux ans OSS technolgies since 95 and would have never imagined to advocate a MS product, but just use VS Code. It's awesome. VS Code managed to by-pass the qualitiy and amount of extensions/plugins in a fraction of time Emacs took decades.

by paines

1/12/2025 at 9:14:09 PM

Kind of weird to compare a sluggish, bug ridden, Javascript application to vim, no?

Same with emacs, now that they've spent some time on performance.

VSCode sits in a weird limbo. It's not an IDE, and it's not an excellent editor. The plugins are usually rudimentary but there's a lot of them. There's no community, instead there's one of the nastiest corporations on the planet faking one.

by cess11

1/13/2025 at 9:21:42 AM

I feel like the oldest cycle in tech is the "easy and good enough" defeating the "more elegant / powerful, but more tricky".

Re VS Code, I wouldn't say it's in a weird limbo - on the contrary, I think that a "smart-ish, extensible editor" is exactly what lots of people actually want. IDEs are too heavy for many folk, vim/emacs too hard, Notepad too dumb. Things like VS Code hit a sweet spot, hence their popularity.

by troad

1/13/2025 at 7:02:54 PM

Emacs is very simple. It has point-and-click menus and tries very hard to generously interpret mistakes and show helpful error messages. I wouldn't call it tricky, unlike the command language in vim.

Power tools aren't as common as regular hammers and saws and so on, i.e. 'less popular', but among professionals few would prefer the unpowered ones just because the threshold to bring one out is lower.

by cess11

1/14/2025 at 2:13:01 AM

That's interesting; I find vim so much more intuitive than emacs. I find commands easier to reason about (and easier on the fingers) than chords. `dd` over `C-a C-k` or `C-S-Backspace`, for example.

I also think the discoverability in emacs, despite the nice point-and-click interface, is always going to be hampered by the idiosyncratic vocabulary. If you don't already know emacs, `Buffers > *scratch*` isn't going to mean anything to you. And if you do know emacs, you're just going to use the chord. So who's the audience for the point-and-click? People who know what scratch buffers are, but don't know how to use emacs? I don't imagine there are many of those.

> Power tools aren't as common as regular hammers and saws and so on, i.e. 'less popular', but among professionals few would prefer the unpowered ones just because the threshold to bring one out is lower.

Agreed, but I suspect many more professional programmers use VS Code than vim and emacs put together. Though I suspect even more use IDEs.

by troad

1/14/2025 at 3:27:16 PM

Maybe, but the basics of text editing are quite obvious. There are large buttons that are easily recognisable, and you'll quickly realise that a buffer is something like an open file.

Sure, that might be the case. I'm not as sure it is good just because it might be the case.

by cess11

1/12/2025 at 10:02:18 AM

VS Code support for Common Lisp is lacking. Alive extension is relatively recent and is a solo effort and thus has significant bugs and is not as feature packed as Vim/Emacs alternatives. For example, it doesn't provide structural editing. It's interaction with sbcl cache seemingly broke my project a few times.

by siknad

1/12/2025 at 8:26:06 AM

Lots of people work with Vim and Emacs day to day, what makes them "long gone" in your opinion?

by Dansvidania

1/12/2025 at 7:27:46 PM

I haven't used emacs so I won't speak to that. But a GUI editor (be it Sublime, Notepad++, VSCode, JetBrains, whatever) does everything vim does and is far easier and more pleasant to use. I think that using vim instead of a GUI editor is kind of like using a hand saw instead of power tools - you can do it, but you're willingly giving up a better option for a worse one. Vim made sense in a day when computers were based around text terminals, but we don't live in that day any more and it doesn't make sense to use tools that are limited by that paradigm any more.

For serious work, a GUI editor (Sublime is my choice) beats the pants off vim. The only situation I use a terminal editor is when I'm editing config files on servers, and vim sucks at that too - nano is far superior for quick and dirty edits to files. I simply do not think there's a use case where vim makes sense any more.

by bigstrat2003

1/12/2025 at 8:18:01 PM

Both Vim and Emacs have GUIs. Emacs can even render your PDFs and webpages, you can have svg icons displayed while browsing directories.

by iLemming

1/13/2025 at 11:59:20 AM

I'm used to vim, editing in anything else is anything but pleasant. It's subjective. It's not about speed or anything. I think slower than I type, so the bottleneck is not my editing speed. But ergonomically it's more pleasant for me to use. Because I barely have to move my hands, and it has very powerful movements.

by vrighter

1/13/2025 at 5:57:35 AM

Neovim beats the pants off Sublime any day. Vim modal editing is the definition of power tools - you have it exactly backward. But like any powerful tool, it needs training.

by lenkite

1/13/2025 at 10:08:38 AM

That's not true. Anything modal editing can do, I can do with Sublime Text, and some things I can do, for example having thousands of cursors simultaneously adding code, can't be done in Vim. If you know how to use your tools, they are power tools.

You will say... oh but my fingers are in the home row! It doesn't matter. I can use the cursor keys just as fast and without having to look at the keyboard, their spatial positions are burned into my brain. And I don't need to change modes to use them! Your way is not superior to my way.

However, the point of all this discussion is that Lisp doesn't provide good enough language servers for modern editors, so Vim and Emacs integration is much better. And that's an orthogonal issue to the fact that some editors allow you to do things one way or another.

by Shorel

1/13/2025 at 11:56:56 AM

> However, the point of all this discussion is that Lisp doesn't provide good enough language servers for modern editors,

They use the "language server" model since a long time, before Microsoft's LSP existed. Thus the need isn't really there, unless one wants to develop with Microsoft products (or similar) and get the needed extensions for Lisp into those Microsoft driven standards. If there were a real need and a real benefit, there would be some better adoption on the Lisp side.

by lispm

1/12/2025 at 8:44:17 AM

Not GP, but I've always found it weird how many people are obsessed with vi/vim and/or Emacs. I get some of the extensibility appeal of Emacs if you're a Lisp fan, but fundamentally I don't understand the appeal of "programming your brain" just to edit code. 90% of my code editing time is spent reading and thinking, not writing or modifying. Memorizing and minimizing (e.g. VimGolf) editor syntax seems like a massive waste of time and cognitive function to me. Modern IDEs have you up and running instantly, and their refactoring tools are really amazing.

I feel like there's been a boom in "editor hipsterism" in the last 10 - 15 years, while everyone has forgotten the variety of novel editors that were made in the 80s and 90s (I've forgotten them, too, I just remember seeing ads and reviews in magazines as a young programmer).

For context, I do have a basic understanding of vim because I run it on servers, but my knowledge doesn't go far beyond search and replace.

by snozolli

1/12/2025 at 3:14:43 PM

To each their own. With Vim, Unix is my IDE. I don't know about the recent interest in these editors that you mention. I've been using vi/Vim for the past 30 years. I take it to every project and job. My fingers already know what to do. I've watched colleagues who I started working with 20 years ago as they've retooled on the latest hotness every 4-5 years. Visual Studio, Netbeans, Eclipse, Jetbrains, VS Code, etc. It doesn't take long to learn to use a new IDE, but they are definitely shorter term investments.

I can do more or less the same thing most folks can with an IDE; I just use external tools. I wouldn't claim that Vim is somehow superior. It's just what I use. Every now and then, I noodle a bit on a personal editor that is to ed what Vim is to vi. At some point, I'll migrate to it.

I think there is a bit of a different philosophy that the editor folks have. I can't speak for them, but I can speak for me. I like to feel closer to the code base. I like to have more of it in my head. The best analogy I've found is that using an editor like Vim or Emacs is closer to driving with a manual transmission and with tight steering controls, compared to driving with an automatic transmission with partial self-driving features found in modern cars. There is definitely something to be said about things like adaptive cruise control, lane keeping assist, GPS navigation, etc. But, if you talk to a manual transmission enthusiast, there is a thrill of feeling closer to the road and being more engaged. Both folks arrive at the destination in the same amount of time. But, if you ask each about their experience, they will have much different views of the drive organized in their head.

by nanolith

1/13/2025 at 10:11:58 AM

> I wouldn't claim that Vim is somehow superior. It's just what I use.

Exactly, that's your editor and you are used to it. There is no reason at all for you to consider to change editors.

I use Sublime Text, it's my editor, it has been for a decade and I am used to it.

I don't have Copilot or similar, and I'm glad I don't. Not interested in such a thing.

by Shorel

1/12/2025 at 5:24:33 PM

To each their own.

And yet I get down-voted for expressing a well-reasoned opinion against vim and Emacs.

I've been using vi/Vim for the past 30 years. I take it to every project and job.

I've rarely used an IDE that didn't allow custom key bindings, often with the ability to select a set from a drop-down list to match other IDEs. I've been using mostly the same keyboard shortcuts across IDEs for over 20 years.

if you talk to a manual transmission enthusiast, there is a thrill of feeling closer to the road and being more engaged

Funny you should say that, because I regularly enrage these types by pointing out that if they can't stay engaged as a driver with an automatic transmission, then the problem is with them, not the car. This is a quasi-religious ritual with these people, and a very low-effort way to get a sense of superiority over others (i.e. every driver on the road before ~1970 had experience with a manual transmission and literally anyone can learn in a few hours. It's not a skill to be proud of).

by snozolli

1/12/2025 at 6:42:39 PM

and a very low-effort way to get a sense of superiority over others... literally anyone can learn in a few hours.

I agree that it is a skill that is easy to learn. The same is true of IDEs. This isn't about skill or superiority, but comfort. Some folks are more comfortable being closer to the machine or the road, as it were. Others are more comfortable having some automation between them and the machine. I think that the better to consider this a matter of personal preference.

The IDE adds a layer of abstraction, and abstraction can be leaky. If you are comfortable with the abstraction, and with the opinionated choices the IDE makes, that's fine. If you are not, that's also fine. All that I ask when I'm bootstrapping a project with a team is that projects be arranged such that they are IDE / editor agnostic. Use standard build configuration / build tools that have appropriate plugins for IDEs, and can also be run in the terminal / command-line. Then, the individual developer can choose to use whichever editor or IDE that developer is comfortable using.

by nanolith

1/13/2025 at 12:20:16 AM

This isn't about skill or superiority, but comfort.

The down-votes that I continue to get in this thread tell a different story.

by snozolli

1/13/2025 at 8:50:43 AM

> And yet I get down-voted for expressing a well-reasoned opinion against vim and Emacs.

Calling people whose editor preferences differ from yours "obsessed" "editor-hipsters" is not a well-reasoned opinion, nor is saying that people who drive manual are engaged in a "quasi-religious ritual" to feel a false "sense of superiority". Those are just insults. Hence the downvotes, I suspect.

No one here is forcing you to use any editor, you've only got people trying to explain to you what they find valuable in the tools you're attacking. You're coming off as someone with a major chip on his shoulder. You may use whatever editor you like, but you should consider extending the same courtesy to others.

by troad

1/12/2025 at 9:20:14 AM

I like vim because the keybindings are familiar everywhere. For small server stuff I use vim, for most coding I use Doom Emacs (vim keybindings), and for Java I use Intellij with vim keybindings.

I mostly use Emacs because of org mode. It's way better than anything else trying to fill this hole. Otherwise I'd probably just use VSCode. But I don't want to add yet another editor to my regular use.

by bcrosby95

1/12/2025 at 2:48:38 PM

Emacs provides far more than just editing. Helps a lot with reading and VC (magit). Just magit would IMHO justify Emacs.

by f1shy

1/12/2025 at 11:22:36 AM

With vim you run factoring tools as an external tools.

Massive wasting of time? with vim you can do something in seconds that with an IDE you would last minutes if not ours.

Check out:

- entr to run commands on modifying files/directories

- plain Makefiles to run your code: git://bitreich.org/english_knight

- LSP and alike tools for your language

by anthk

1/12/2025 at 5:12:22 PM

Massive wasting of time?

I feel like you only read half of that sentence.

entr to run commands on modifying files/directories

Alt-Tab to the command console that I always have running.

plain Makefiles to run your code

I have no idea what the advantage is here. F5 to run my code, including scripted deployment.

LSP and alike tools for your language

I don't know what this means.

by snozolli

1/12/2025 at 10:31:25 AM

i prefer to use the mouse as little as possible, i feel more productive when I can stay on the home-row of the keyboard, that is primarily it for me. This is because hotkeys are more direct, exact and easier to memorize than mouse motions

it helps that vim bindings are adopted in many places so learning and using them ports well to browsing and even managing windows (vimium and aerospace respectively)

secondarily, while i don't think using the terminal is generally better than GUI I tend to work in the terminal anyway, so keeping text editing there makes sense.

by Dansvidania

1/13/2025 at 10:16:14 AM

> This is because hotkeys are more direct, exact and easier to memorize than mouse motions

Did you ever try Opera 5.12 mouse gestures? That was a feature that completely contradicted your statement. The gestures were direct, unambiguous, and easier to memorize than any set of Ctrl+key shortcuts.

Sadly, that feature has never been fully replicated. The closest I found is Vivaldi, which I am using now, but it is not exactly the same.

by Shorel

1/13/2025 at 10:21:04 AM

I never tried. I will take a look.

by Dansvidania

1/12/2025 at 8:40:04 PM

> I've always found it weird how many people are obsessed with vi/vim and/or Emacs.

Because you've never truly done it. Like someone who has seen all three sides, I can tell you this: I have never, even once, even for a second, ever regretted my time invested in learning Vim and Emacs. Vim is hands-down the best mental model for navigating through text - I use it everywhere - in my editor, in my terminal, in my browser; heck, I use it system-wide - in my window manager. It's immensely empowering - being able to control things without losing context - your fingertips are in control of everything, you don't even need to shift your hand to touch the mouse or arrow keys. It also liberates you from learning myriad key combinations for every single app, it gives you freedom from having to learn, remember and having to perform weird dactylar dance, where sometimes you can't even reach the exact keys without looking down at your keyboard, not to mention the ergonomics.

And then Emacs. OMG, Emacs is so amazing, you just have no idea. The things you can do in Emacs are hard to describe in words - you just need to see it.

> 90% of my code editing time is spent reading and thinking, not writing or modifying

I spent most of my time taking notes. Emacs is the best tool for that. Matter of fact, I find Emacs is the best tool for any kind of text manipulation. I don't even type anything longer than three words in any app anymore. I'm typing this exact comment in Emacs right now. Why wouldn't I? I have all the tools I need at my disposal - spellchecking, dictionaries, translation, etymology and definition lookup, access to various LLMs - chatgpt, claude, ollama, perplexity, and others, search engines - here's a real, practical example: I would type a search query once and it sends requests to Google, Wikipedia, GitHub, YouTube, etc. I then can pick up the YouTube url, open the video and control its playback while typing - I can pause, mute, resume, speed up the video. All that with the emphasis of the main task at hand - taking notes. Done without leaving the window where the notes are being typed, without having to switch your focus - your mind remains "in the zone". I'm telling you - that's some blackmagic fuckery for staying productive and happy. It's enormously fun when you have complete control over the things happening on your screen.

> I've always found it weird

There's nothing truly "weird" about it. If you are a computer programmer, you do want to be in control of the computing happening on your computer. It's rather weird when there's the opposite - when computer programmers become merely "users", when they are told that "you're holding it wrong" and "users don't know what they want". I for one do exactly what I want - I want the shit on my computer to work and work on my terms, not anyone else's.

by iLemming

1/13/2025 at 12:27:29 AM

I have all the tools I need at my disposal

Yes, we've all heard the saying that Emacs is an operating system with a text editor built in.

I for one do exactly what I want - I want the shit on my computer to work and work on my terms, not anyone else's.

That's exactly what I get out of the IDEs I've used for decades. This whole argument is so weird, disingenuous, and full of vague strawmen. Just because I don't see the value in investing the time that you have doesn't mean that I'm for giving up control or whatever you were trying frame me as.

Anyway, I'm done here. This site is full of toxic people who are offended that someone doesn't choose the same editor and habits that they do, and any dissent is to be punished.

by snozolli

1/13/2025 at 1:32:52 AM

I don't think I've made any arguments at all, and definitely haven't said anything disingenuous. I'm not trying to sell you dogmas, and I'm not telling you how to live your life. I have only attempted to share a glimpse of the world you clearly have little understanding of - the assumption that I (not unreasonably) made based on your own words.

Perhaps my usage of pronouns in the last paragraph was confusing; I apologize for that. Since we're talking on a public forum, the "you" wasn't aimed specifically at your persona; I meant it in a generic sense, talking about a "proverbial" programmer.

> This site is full of toxic people who are offended that someone doesn't choose the same editor

I don't know where you're getting this kind of vibe from; my comments are free of toxicity. I think this particular website and the world in general is full of all sorts of people. And if you genuinely try to find helpful and beneficial thoughts and inspiration, you may find some - even within the words of criticism and discouragement. Conversely, someone who sees toxicity whenever they don't get conformance with their views may reap only bitterness and dissatisfaction.

Perhaps you should reflect on the source of your anger; just don't waste energy searching for it in my statements - after all, I merely showed you possibilities. I never forced you toward them - the choice to step through or turn away remains entirely in your hands.

by iLemming

1/13/2025 at 8:12:59 AM

> That's exactly what I get out of the IDEs I've used for decades. This whole argument is so weird, disingenuous, and full of vague strawmen. Just because I don't see the value in investing the time that you have doesn't mean that I'm for giving up control or whatever you were trying frame me as.

I used IDEs also all the time. Makes sense to me.

> Anyway, I'm done here. This site is full of toxic people who are offended that someone doesn't choose the same editor and habits that they do, and any dissent is to be punished.

Yeah, that's weird. You can use all kinds of editors you like. In the case of Lisp, there are arguments that good support for editing Lisp and for interaction with a Lisp runtime is useful (since Lisp is often used interactively). But several IDEs and editors can do that.

Just wanted to give you the impression that are others, who like IDEs and similar tools. ;-)

by lispm

1/13/2025 at 2:32:27 PM

> VS Code managed to by-pass the qualitiy and amount of extensions/plugins in a fraction of time Emacs took decades.

I get the impression that the VSCode has a rather fractured, limited, malware-infested[1][2], JavaScript-churn inundated plugin ecosystem. You have lots of choice, but I'm would be just as hesitant using a random extension as I would downloading some random executable and running it. On the other hand, I'm genuinely surprised (in a good way) how OCD some Emacs users are with the code I publish to MELPA.

[1] https://arxiv.org/abs/2411.07479 [2] https://www.bankinfosecurity.com/visual-studio-code-has-mali...

by uludag

1/12/2025 at 6:55:25 PM

Thanks, but no thanks.

I don't like vscode extensions advertising to me every 5 seconds, auto-downgrading the free versions of extensions, auto-installing aux tools every 5 seconds, having a 400 MB RSS chromium runtime (remember Eight Megabytes And Constantly Swapping? VS code is much worse; and it's also just a plain text editor); nerfing the .net debugger and breaking hot reload on purpose in VSCodium; telemetry, .... it's so noisy all the time. You are using this? On purpose?!

VS code is basically the same idea as emacs, just the MVP variant and with a lot of questionable technology choices (Javascript? Electron? Then emulate terminal cells anyway and manually copy cell contents? uhhh. What is this? Retrofuturism?) and done with the usual Microsoft Embrace-Extend-Extinguish tactics (nerfing pylance, funny license terms on some extensions that the extensions are only allowed to be used in their vscode etc).

So if you didn't like emacs you probably wouldn't like vscode either.

Also, if you use anything BUT emacs for Lisp development, what do you use that doesn't have a jarring break between the Lisp image and you? vim seems weird for that use case :)

emacs is very very good for Lisp development.

On the other hand, VSCode for Lisp is very flaky and VSCode regularily breaks your Lisp projects. Did you try it?

Because of your comment I tried VSCode again and now about 20 extensions (one of them "Alive", a Lisp extension for vscode) complain about now missing

  "Dev container: Docker from Docker Compose"
(keep in mind they worked before and I didn't change anything in vscode--I hadn't even run VSCode for 8 months or so) and when I try to fix that by clicking on the message in the extension manager the message immediately disappears from all 20 extensions in the manager (WTF?) and I get:

>>./logs/20250112T181356/window1/exthost/ms-vscode-remote.remote-containers/remoteContainers-2025-01-12T17-13-58.234Z.log: >>>> Executing external compose provider "/home/dannym/.guix-home/profile/bin/podman-compose". Please see podman-compose(1) for how to disable this message. <<<< >a239310d8b933dc85cc7671d2c90a75580fc57a309905298170eac4e7618d0c1 >Error: statfs /var/run/docker.sock: no such file or directory >Error: no container with name or ID "serverdevcontainer_app_1" found: no such container

... because it's using podman (I didn't configure that--vscode did that on its own, incompletely. Also, it thinks that means having a docker/podman service running as root has to be a thing then (instead of rootless podman). Funny thing is I use podman extensively. I don't wanna know how bad it would be if I HADN'T set podman up already).

So it didn't actually fix anything, but it removed the error message. I see. And there's no REPL for the editor--so I can't actually find out details, let alone fix anything.

I had thought emacs DX was bad--but I've revised my opinion now: compared to vscode DX, emacs DX is great. You live with VSCode if you want to.

And note, vscode was made after emacs was made. There's no excuse for this.

I think this now was about all the time that I want to waste on this thing, again.

How is this a problem in 2025? shakes head

>VS Code managed to by-pass the qualitiy and amount of extensions/plugins in a fraction of time Emacs took decades.

Yeah? Seems to me these vscode extensions are written in crayon. Bad quality like that would never make it into emacs mainline. And it's not even strictly about that! I wonder who would write a developer tool that the developer can't easily debug its own extensions in (yes, I know about Ctrl-Shift-P). That flies about as well as a lead balloon.

For comparison, there's emacs bufferenv that does dev containerization like this and it works just fine. Configuration: 1 line--the names of the containerfiles one wants it to pick up. Also, if I wanted to debug what it did (which is rare) I could just evaluate any expression whatsoever in emacs. ("Alt-ESC : «expression»" anywhere)

PS. manually running "podman-compose up" in an example project as a regular user works just fine--starts up the project and everything needed. So what are they overcomplicating here? Pipes too hard?

PPS. I've read some blog article to make socket activation work for rootless podman[1] but it's not really talking about vscode. Instead, it talks how one would set up "linger" so that the container stays there when I'm logged out. So that's not for dev containers (why would I possibly want that there? I'm not ensuring Heisenbugs myself :P).

[1] https://github.com/containers/podman/blob/main/docs/tutorial...

by dannymi

1/12/2025 at 8:06:24 PM

> they had their time which is long gone

Haha, yeah, sure, but of course, no! Similar shit has been said so many times since 1990s. Yet both Vim and Emacs still have vibrant communities, have dedicated conferences, they get mentioned almost every week - here on HN, and every day on Reddit.

Emacs, in experienced hands, absolutely kicks everything out of the ballpark; it's just hands-down the best tool with unmatched text manipulation capabilities. Anyone who says otherwise simply is unaware what you can do in Emacs.

Can anyone in the grand community of VSCode users claim to have a workflow that involves:

- Reading a pdf where the colors match the current color scheme? The scheme that automatically adjusts the colors based on time of the day (because Emacs has built-in solar and lunar calendars)?

- Where they do annotate the said pdf in their notes, where you can jump to the places in pdf from the notes and vice-versa? Where you can scroll the pdf, without even having to switch windows, because you're in the middle of typing?

- Where you can open a video and control its playback - pausing and resuming it in place, directly from your editor, whilst typing?

- Where you also extract subtitles and copy some text chunks for your notes? Where you can run LLM to extract summary for your notes of the said transcript?

- Where you can resume the video-playback at some position in the transcript? Where you can watch the video and chunks of the transcript text get automatically highlighted - the karaoke style?

- Where you can simply type 'RFC-xxx' and despite that being a plain text entry, Emacs intelligently recognizes what that is and lets you browse the RFC entry, in-place, without even googling for it? Or similarly have plain-text of e.g., 'myorg/foo#34' and browse that Pull-Request and even perform the review with diffs and everything?

- Speaking of googling, can you type a search query only once and let it run through different places, finding things in Google, YouTube, Wikipedia, DuckDuckGo, GitHub, your browser's history and personal emails? Or any other places, since it's highly configurable?

- Do you use translation, dictionaries, thesaurus, etymology and definition lookup for any words and phrases, in the midst of typing? I have bound "auto-correct previous typo" to a double tap of the comma key - it's super convenient. Can you do something like that in VSCode easily?

- Do you edit code comments and docstrings in the code, treating them as markdown - with all the syntax highlighting, preview, and other perks?

- Do you have embedded LaTeX formulas directly in your notes?

And that's just a tiny fraction of things I personally do in Emacs - it's just the tip of the iceberg. There are tons of other interesting and highly pragmatic Emacs packages people use for various kinds of tasks. Speaking of packages - my config contains over 300 different Emacs packages, and I still can restart and load it under a second. Can you imagine any VS Code user having installed even half of that many plugins? Would that still be a "workable" environment?

by iLemming

1/14/2025 at 5:30:14 AM

How do you get started on learning all that? I’ve never come close to getting such productivity out of Emacs.

by selestify

1/14/2025 at 4:39:39 PM

Hmm... well, it's of course very difficult to explain the process in a single comment, besides, there's no exact prescribed "recipe" for it, unfortunately.

I'd say the mental model for developing the 'Emacs way of thinking' lies, first and foremost, in realizing that Emacs is not "an editor that uses Lisp for configuring it," but rather a 'Lisp Machine' - calling it that would be a stretch, of course. Allow me this simplification here. Emacs is a 'Lisp REPL' that has a built-in editor. That means, instead of focusing on the features of the editor, it's better to study Emacs Lisp and the ways of using it to shape the editor's features.

The great way of developing knack for Lisp is to start with figuring out mainly two things: first, is so called "REPL-driven development". For Elisp that basically means learning the ways of evaluating symbolic-expressions: https://www.gnu.org/software/emacs/manual/html_node/emacs/Li...

Second thing, even though some experts would argue for being optional, I still believe is very important - structural editing commands: ways for quickly moving symbolic expressions around, expanding and transposing them, etc. - you do want to control those (seemingly pesky at first) parenthesis. There are multiple different ways of dealing with those - paredit, smartparens, parinfer, etc.

Then, learning how to effectively search through built-in help, finding the functions, commands, variables, etc. - the stock features already good, although the keybindings and navigating through them might be confusing, there are different packages that can help - consult-info, helpful, etc.

And then, one basically has to get annoyed by small inefficiencies in their workflow. Examples? Do you often have to copy&paste the url of the current tab in your browser while typing? Seemingly simple activity, still requires you to: switching to the browser, focusing on the address bar, copying the url, switching back to the editor, pasting the url, sometimes, it doesn't end there, you need to switch back to the browser, copy the description of the page, switch back to the editor, paste the description, wrap things in a markdown-type of link, etc. Most people would say: "what a nonsense, it's not a big deal, like at all...". But if you think for a minute, how often do you have to do that? Every day, during the lifetime of your computer use. These kind of small inefficiencies are not really distractions for the brain, in fact, that all is over-stimulation of neurons. You may think that you've done that so many times, it actually happens so quickly, you don't even think about it, yet, it still forces your brain "out of the zone", even though might be just for a second.

Another personal example: at some point, I got annoyed by my own typing - I make typos all the time, so I needed a quicker way of automatically fixing typos as I type. First, I wrote a command that does that, and then I bound it to a key - to a double tap of the comma. I'd be typing, and typing, then a typo gets highlighted, I'd quickly tap comma twice and it gets fixed with 90% of predictability. Sometimes it would guess a wrong word, and then if I keep pressing the comma, it would cycle through variants. It feels great beyond words, and it is so instinctive and fast, I don't get distracted at all. Imagine a guitar player with a performance so wild that strings get snapped every few seconds. Imagine that instead of having to replace the entire guitar, there's a special mechanism on it that quickly installs a new string and tunes it up immediately, so the performance goes on without any hiccups. That's what using Emacs often feels to me.

So, my personal advice - simply be annoyed by small things. Then, put them on your TODO list. At some point, you'll get annoyed again and again. Note it each time. And then, try to find a better way to do that thing. The rate of getting more productive is proportional to the level of accrued annoyance.

by iLemming