12 ms·

Why I Chose Common Lisp

363 points by djha-skin 2y ago

chii 2y ago
> 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.
- huahaiy 2y ago
  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 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.
  - IshKebab 2y ago
    > 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.
    - chii 2y ago
      when engineers say it's a solved problem, they mean it in the same way as a mathematician saying a theorem is trivially proved.
      - deleted 2y ago
        [deleted]
      - iLemming 2y ago
        > 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. (:
    - macmac 2y ago
      Look at the hoops OP had to jump through to get SBCL working on Windows. I think Graal would compared favourably with that.
      - anthk 2y ago
        What did you mean? Can't the user just download Portacle and use it? https://portacle.github.io/ https://portacle.github.io/ Problem solved.
        chii 2y ago
        Right at the top of the article, the author outlines the requirement was that it must be usable within vim.
        anthk 2y ago
        Not an issue for Common Lisp, you can use whatever you like, but interacting with a REPL gives you superpowers.
        macmac 2y ago
        Not really. OP needs to build executables. It is documented here: https://blog.djhaskin.com/blog/release-common-lisp-on-your-first-day/ https://blog.djhaskin.com/blog/release-common-lisp-on-your-f...
        vindarel 2y ago
        Portacle ships SBCL so one can build executables when using Portacle.
      - IshKebab 2y ago
        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.
  - djha-skin 2y ago
    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.
    - huahaiy 2y ago
      No. I have looked at your code. You did not use the mentioned https://github.com/clj-easy/graal-build-time 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.
      - KingMob 2y ago
        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.
- m1n1 2y ago
  what are you referring to when you say a language can sell out?
stevebmark 2y ago
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?
- neuroelectron 2y ago
  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.
- IshKebab 2y ago
  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?
  - weikju 2y ago
    Probably had to be a Lisp, considering the OP was coming from Clojure. Rust and Go fail that (unwritten) requirement.
    - deleted 2y ago
      [deleted]
- forgotpwd16 2y ago
  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.
nomilk 2y ago
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).
- ofalkaed 2y ago
  >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 https://github.com/lem-project/lem
  - djtango 2y ago
    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
BreakMaker9000 2y ago
Wondering whether a dialect like Jank [1] may be worth a shot? [1] https://jank-lang.org/ https://jank-lang.org/
- cylinder714 2y ago
  Its author is quitting his job to work on it full time: https://jank-lang.org/blog/2025-01-10-i-quit-my-job/ https://jank-lang.org/blog/2025-01-10-i-quit-my-job/
agentkilo 2y ago
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.
- chikere232 2y ago
  That's pretty cool, but also, get version control
  - pizza 2y ago
    Version control won't help if the repo itself has been lost to the sands of time
    - chikere232 2y ago
      Very true. Get backups
      - wodenokoto 2y ago
        Which the client might be responsible for because the contractor might not be allowed to retain the IP
        crispyambulance 2y ago
        You're "allowed". Just keep it to yourself.
packetlost 2y ago
I went on a similar journey a couple of years ago and ended up on Gerbil Scheme instead.
- tasuki 2y ago
  Care to explain why?
  - packetlost 2y ago
    Fast, Scheme is more to my tastes, a real module system, real multicore support, (syntax-rules).
- matrix12 2y ago
  Great choice. Fully static binaries are a win.
billmcneale 2y ago
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.
- anonzzzies 2y ago
  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.
  - f1shy 2y ago
    > no updates for 10 years because it just works! Maybe I’m crazy, but that is what I like from Lisp
    - anonzzzies 2y ago
      yep, same.
- bmacho 2y ago
  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.
  - BoiledCabbage 2y ago
    > 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.
Volundr 2y ago
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.
- iLemming 2y ago
  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.
pntripathi9417 2y ago
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 https://github.com/camsaul/methodical library quite well and the performance is better than default multimethods in core clojure implementation.
thih9 2y ago
Related, Janet: https://janet-lang.org/ 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 https://github.com/janet-lang/janet
- draven 2y ago
  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.
- rcarmo 2y ago
  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.
brabel 2y ago
> 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.
- anonzzzies 2y ago
  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.
  - deleted 2y ago
    [deleted]
- anthk 2y ago
  #lisp and it's offtopic channel #lispcafe at irc://libera.chat are far better. Also, comp.list at Usenet.
  - fuzztester 2y ago
    Did you mean comp.lang.lisp ? Because that's the usual convention, like comp.lang.c, .python, etc.
    - anthk 2y ago
      yes, I made a typo.
- susam 2y ago
  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 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 https://web.libera.chat/#lispcafe
sundarurfriend 2y ago
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 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/ https://juliafolds2.github.io/OhMyThreads.jl/stable/ [2] https://discourse.julialang.org/ https://discourse.julialang.org/ [3] https://github.com/JuliaDatabases/SQLite.jl https://github.com/JuliaDatabases/SQLite.jl [4] https://github.com/JuliaFolds2/Transducers.jl https://github.com/JuliaFolds2/Transducers.jl
- djha-skin 2y ago
  Mfiano wrote about this. https://mfiano.net/posts/2022-09-04-from-common-lisp-to-julia/ https://mfiano.net/posts/2022-09-04-from-common-lisp-to-juli... . (By the last report, mfiano came back to CL.) Refutation: https://gist.github.com/digikar99/24decb414ddfa15a220b27f6748165d7 https://gist.github.com/digikar99/24decb414ddfa15a220b27f674...
deleted 2y ago
[deleted]
oldpersonintx 2y ago
[dead]
linkerdoo 2y ago
[flagged]
- deleted 2y ago
  [deleted]
- mseepgood 2y ago
  Win what?
paines 2y ago
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.
- Dansvidania 2y ago
  Lots of people work with Vim and Emacs day to day, what makes them "long gone" in your opinion?
  - snozolli 2y ago
    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.
    - bcrosby95 2y ago
      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.
jwr 2y ago
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.
- djha-skin 2y ago
  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.
  - jwr 2y ago
    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 :-)
    - lispm 2y ago
      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.
linkerdoo 2y ago
[flagged]
- dokyun 2y ago
  You'll lose first.
pjmlp 2y ago
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.
- anthk 2y ago
  There's Emacs and Slime too OFC. Also, Quicklisp/Ultralisp aren't ASDF, you are pretty outdated... https://www.quicklisp.org/beta/ https://www.quicklisp.org/beta/ https://ultralisp.org/ https://ultralisp.org/
  - pjmlp 2y ago
    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.
darthrupert 2y ago
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.
- worthless-trash 2y ago
  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.
  - andsoitis 2y ago
    > 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.
    - worthless-trash 2y ago
      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.
- baq 2y ago
  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.
quibono 2y ago
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?
- susam 2y ago
  I began learning Common Lisp (CL) from the Common Lisp HyperSpec (CLHS): <https://www.lispworks.com/documentation/HyperSpec/Front/Contents.htm https://www.lispworks.com/documentation/HyperSpec/Front/Cont...>. When I began learning CL about two decades ago, I did know of any other easily available source, so CLHS was my only source back then and I think it has served me well. A popular recommendation these days is Practical Common Lisp (by Peter Seibel): <https://gigamonkeys.com/book/ https://gigamonkeys.com/book/>.
  - susam 2y ago
    Correction: s/I did know/I did not know/
- wwfn 2y ago
  Not standard, but hopefully worth mentioning: the thing that's clicked best for me is the docs on https://ciel-lang.org/ 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 https://news.ycombinator.com/item?id=41401415
- lispshillin291 2y ago
  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/ https://www.cs.cmu.edu/~dst/LispBook/
- sandbach 2y ago
  There's this great post by Steve Losh: https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/ https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/
Naru41 2y ago
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 https://www.youtube.com/watch?v=HM1Zb3xmvMc
- crispyambulance 2y ago
  Every programming language should have a music video!
  - iLemming 2y ago
    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 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.
- tiberious726 2y ago
  I always preferred this one: https://youtu.be/5-OjTPj7K54?si=TYuCLJ9_2WvRHcHM https://youtu.be/5-OjTPj7K54?si=TYuCLJ9_2WvRHcHM
  - emmanueloga_ 2y ago
    https://www.youtube.com/watch?v=a0YrCABCOEY https://www.youtube.com/watch?v=a0YrCABCOEY
neilv 2y ago
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/ https://pkgs.racket-lang.org/", or Chicken, "http://eggs.call-cc.org/5/ 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.
- nsm 2y ago
  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.
Horffupolde 2y ago
Common Lisp is great until it isn’t.
- Guthur 2y ago
  And then you grab a macro, extend it and it's great again ;)
transfire 2y ago
Jank
bigpeopleareold 2y ago
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.
- WorldMaker 2y ago
  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.
aidenn0 2y ago
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?"
joshlemer 2y ago
Does anyone use Clojure CLR? How is the startup time for that?
- KingMob 2y ago
  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).
  - joshlemer 2y ago
    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.
    - KingMob 2y ago
      Not that I'm aware of. ClojureCLR was pretty much just made by Ramsey Nasser as a vehicle for his experimental video game work. I never heard of anyone else using it (though I'm sure somebody tried), so I'd bet against it having a better AOT experience. Just my $.02, anyway.
xiaodai 2y ago
Cos shipping things is not a concern
gigatexal 2y ago
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
- WorldMaker 2y ago
  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.
  - kazinator 2y ago
    Hey same for 25 years of my life, and counting.
- kazinator 2y ago
  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.
rubenvanwyk 2y ago
Curious if you didn't look at F#? Seems like it would've been a good fit (perhaps except for the Vim support?)
- WorldMaker 2y ago
  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.)
ags1905 2y ago
What about free pascal compiler and Lazarus IDE?

363 points by djha-skin 2y ago

chii 2y ago

> 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.

huahaiy 2y ago
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 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.
- IshKebab 2y ago
  > 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.
  - chii 2y ago
    when engineers say it's a solved problem, they mean it in the same way as a mathematician saying a theorem is trivially proved.
    - deleted 2y ago
      [deleted]
    - iLemming 2y ago
      > 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. (:
  - macmac 2y ago
    Look at the hoops OP had to jump through to get SBCL working on Windows. I think Graal would compared favourably with that.
    - anthk 2y ago
      What did you mean? Can't the user just download Portacle and use it? https://portacle.github.io/ https://portacle.github.io/ Problem solved.
      - chii 2y ago
        Right at the top of the article, the author outlines the requirement was that it must be usable within vim.
        anthk 2y ago
        Not an issue for Common Lisp, you can use whatever you like, but interacting with a REPL gives you superpowers.
      - macmac 2y ago
        Not really. OP needs to build executables. It is documented here: https://blog.djhaskin.com/blog/release-common-lisp-on-your-first-day/ https://blog.djhaskin.com/blog/release-common-lisp-on-your-f...
        vindarel 2y ago
        Portacle ships SBCL so one can build executables when using Portacle.
    - IshKebab 2y ago
      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.
- djha-skin 2y ago
  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.
  - huahaiy 2y ago
    No. I have looked at your code. You did not use the mentioned https://github.com/clj-easy/graal-build-time 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.
    - KingMob 2y ago
      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.
m1n1 2y ago
what are you referring to when you say a language can sell out?

stevebmark 2y ago

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?

neuroelectron 2y ago
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.
IshKebab 2y ago
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?
- weikju 2y ago
  Probably had to be a Lisp, considering the OP was coming from Clojure. Rust and Go fail that (unwritten) requirement.
  - deleted 2y ago
    [deleted]
forgotpwd16 2y ago
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.

nomilk 2y ago

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).

ofalkaed 2y ago
>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 https://github.com/lem-project/lem
- djtango 2y ago
  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

BreakMaker9000 2y ago

Wondering whether a dialect like Jank [1] may be worth a shot? [1] https://jank-lang.org/ https://jank-lang.org/

cylinder714 2y ago
Its author is quitting his job to work on it full time: https://jank-lang.org/blog/2025-01-10-i-quit-my-job/ https://jank-lang.org/blog/2025-01-10-i-quit-my-job/

agentkilo 2y ago

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.

chikere232 2y ago
That's pretty cool, but also, get version control
- pizza 2y ago
  Version control won't help if the repo itself has been lost to the sands of time
  - chikere232 2y ago
    Very true. Get backups
    - wodenokoto 2y ago
      Which the client might be responsible for because the contractor might not be allowed to retain the IP
      - crispyambulance 2y ago
        You're "allowed". Just keep it to yourself.

packetlost 2y ago

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

tasuki 2y ago
Care to explain why?
- packetlost 2y ago
  Fast, Scheme is more to my tastes, a real module system, real multicore support, (syntax-rules).
matrix12 2y ago
Great choice. Fully static binaries are a win.

billmcneale 2y ago

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.

anonzzzies 2y ago
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.
- f1shy 2y ago
  > no updates for 10 years because it just works! Maybe I’m crazy, but that is what I like from Lisp
  - anonzzzies 2y ago
    yep, same.
bmacho 2y ago
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.
- BoiledCabbage 2y ago
  > 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.

Volundr 2y ago

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.

iLemming 2y ago
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.

pntripathi9417 2y ago

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 https://github.com/camsaul/methodical library quite well and the performance is better than default multimethods in core clojure implementation.

thih9 2y ago

Related, Janet: https://janet-lang.org/ 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 https://github.com/janet-lang/janet

draven 2y ago
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.
rcarmo 2y ago
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.

brabel 2y ago

> 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.

anonzzzies 2y ago
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.
- deleted 2y ago
  [deleted]
anthk 2y ago
#lisp and it's offtopic channel #lispcafe at irc://libera.chat are far better. Also, comp.list at Usenet.
- fuzztester 2y ago
  Did you mean comp.lang.lisp ? Because that's the usual convention, like comp.lang.c, .python, etc.
  - anthk 2y ago
    yes, I made a typo.
susam 2y ago
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 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 https://web.libera.chat/#lispcafe

sundarurfriend 2y ago

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 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/ https://juliafolds2.github.io/OhMyThreads.jl/stable/ [2] https://discourse.julialang.org/ https://discourse.julialang.org/ [3] https://github.com/JuliaDatabases/SQLite.jl https://github.com/JuliaDatabases/SQLite.jl [4] https://github.com/JuliaFolds2/Transducers.jl https://github.com/JuliaFolds2/Transducers.jl

djha-skin 2y ago
Mfiano wrote about this. https://mfiano.net/posts/2022-09-04-from-common-lisp-to-julia/ https://mfiano.net/posts/2022-09-04-from-common-lisp-to-juli... . (By the last report, mfiano came back to CL.) Refutation: https://gist.github.com/digikar99/24decb414ddfa15a220b27f6748165d7 https://gist.github.com/digikar99/24decb414ddfa15a220b27f674...

deleted 2y ago

[deleted]

oldpersonintx 2y ago

[dead]

linkerdoo 2y ago

[flagged]

deleted 2y ago
[deleted]
mseepgood 2y ago
Win what?

paines 2y ago

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.

Dansvidania 2y ago
Lots of people work with Vim and Emacs day to day, what makes them "long gone" in your opinion?
- snozolli 2y ago
  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.
  - bcrosby95 2y ago
    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.

jwr 2y ago

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.

djha-skin 2y ago
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.
- jwr 2y ago
  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 :-)
  - lispm 2y ago
    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.

linkerdoo 2y ago

[flagged]

dokyun 2y ago
You'll lose first.

pjmlp 2y ago

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.

anthk 2y ago
There's Emacs and Slime too OFC. Also, Quicklisp/Ultralisp aren't ASDF, you are pretty outdated... https://www.quicklisp.org/beta/ https://www.quicklisp.org/beta/ https://ultralisp.org/ https://ultralisp.org/
- pjmlp 2y ago
  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.

darthrupert 2y ago

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.

worthless-trash 2y ago
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.
- andsoitis 2y ago
  > 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.
  - worthless-trash 2y ago
    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.
baq 2y ago
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.

quibono 2y ago

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?

susam 2y ago
I began learning Common Lisp (CL) from the Common Lisp HyperSpec (CLHS): <https://www.lispworks.com/documentation/HyperSpec/Front/Contents.htm https://www.lispworks.com/documentation/HyperSpec/Front/Cont...>. When I began learning CL about two decades ago, I did know of any other easily available source, so CLHS was my only source back then and I think it has served me well. A popular recommendation these days is Practical Common Lisp (by Peter Seibel): <https://gigamonkeys.com/book/ https://gigamonkeys.com/book/>.
- susam 2y ago
  Correction: s/I did know/I did not know/
wwfn 2y ago
Not standard, but hopefully worth mentioning: the thing that's clicked best for me is the docs on https://ciel-lang.org/ 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 https://news.ycombinator.com/item?id=41401415
lispshillin291 2y ago
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/ https://www.cs.cmu.edu/~dst/LispBook/
sandbach 2y ago
There's this great post by Steve Losh: https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/ https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/

Naru41 2y ago

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 https://www.youtube.com/watch?v=HM1Zb3xmvMc

crispyambulance 2y ago
Every programming language should have a music video!
- iLemming 2y ago
  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 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.
tiberious726 2y ago
I always preferred this one: https://youtu.be/5-OjTPj7K54?si=TYuCLJ9_2WvRHcHM https://youtu.be/5-OjTPj7K54?si=TYuCLJ9_2WvRHcHM
- emmanueloga_ 2y ago
  https://www.youtube.com/watch?v=a0YrCABCOEY https://www.youtube.com/watch?v=a0YrCABCOEY

neilv 2y ago

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/ https://pkgs.racket-lang.org/", or Chicken, "http://eggs.call-cc.org/5/ 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.

nsm 2y ago
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.

Horffupolde 2y ago

Common Lisp is great until it isn’t.

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

transfire 2y ago

Jank

bigpeopleareold 2y ago

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.

WorldMaker 2y ago
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.

aidenn0 2y ago

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?"

joshlemer 2y ago

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

KingMob 2y ago
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).
- joshlemer 2y ago
  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.
  - KingMob 2y ago
    Not that I'm aware of. ClojureCLR was pretty much just made by Ramsey Nasser as a vehicle for his experimental video game work. I never heard of anyone else using it (though I'm sure somebody tried), so I'd bet against it having a better AOT experience. Just my $.02, anyway.

xiaodai 2y ago

Cos shipping things is not a concern

gigatexal 2y ago

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

WorldMaker 2y ago
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.
- kazinator 2y ago
  Hey same for 25 years of my life, and counting.
kazinator 2y ago
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.

rubenvanwyk 2y ago

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

WorldMaker 2y ago
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.)

ags1905 2y ago

What about free pascal compiler and Lazarus IDE?