38 ms·

Embracing Common Lisp in the modern world

183 points by joaogui1 3y ago

deleted 3y ago
[deleted]
reikonomusha 3y ago
Common Lisp has bad marketing (even OCaml has Twitch streamers and "influencers" now), and bad support for general editors, both of which make it a non-starter for most curious people who have an afternoon to try something. But behind all that is magnificent activity for those who got over the initial potential energy barrier. Just to give some examples: 1. SBCL, the most popular open source implementation of Lisp, is seeing potentially two new garbage collectors, one of which is merged and open to beta testing. One of them is a parallel collector written by a university student (!!) which blows my mind. 2. SBCL has better and better support for deploying Lisp as a C-compatible shared library, using SBCL-LIBRARIAN. It makes it play nicer with other applications in C and Python, without the baggage of process wrangling and thick RPC (IPC/servers, serialization, ...). 3. Coalton is another exciting development that allows a Haskell type system and "Lisp-1" functional programming in Common Lisp. That means type classes (or traits), something Lisp hasn't really had a proper notion of, and full type inference. Persistent sequences based off of RRB-trees were recently merged [1], and interestingly, they're implemented purely in Coalton [2]. That means Clojure-like seqs. It's interesting to see users of Lisp generating the above ideas and libraries, not a special in-group of committees, "official" developers, etc. [1] https://coalton-lang.github.io/reference/#seq-type https://coalton-lang.github.io/reference/#seq-type [2] https://github.com/coalton-lang/coalton/blob/main/library/seq.lisp https://github.com/coalton-lang/coalton/blob/main/library/se...
- posix_monad 3y ago
  Isn't Clojure the most mainstream Lisp at this point?
  - reikonomusha 3y ago
    I'd say so, but for many, it's "dead on arrival" for a variety of reasons: Java-centric, unabashedly dynamically typed (favoring instead a slightly more eccentric way of enforcing contracts), etc. Unfortunately, a lot of Scheme and Common Lisp people don't like Clojure a whole lot because it gave up on a variety of things that group has treasured.
    - 7thaccount 3y ago
      It also assumes significant Java knowledge, so I kept finding myself at a dead end where it assumes I know the Java library way to do something and can just call it. I tried Clojure for the Brave and True and Living Clojure. I kept thinking that I wasn't getting anything I couldn't already do in Python (at least for my uses), but there's a lot of baggage like emacs + cider...etc.
      - ryanobjc 3y ago
        The gap between the clojure libs and the java libs and actually calling java is a jarring experience and really isn't a plus. While in theory the java interop is a selling point, if you don't need that it ends up being extra syntactical complexity. Now I haven't coded extensively in clojure, so a lot of it stylistic unfamiliarity. It does hold back people from adopting clojure. One reason why I'm excited never to use the JVM again is the huge memory footprint it uses. The best practices for production java is to figure out how much ram your process will need max under normal (not leaking) usage... and set both max and min ram to that (Xmx and Xms). It's a real hog on ram, and when running under clustered tools like k8 with can do memory overcommits it really reduces your flexibilty. I'm super psyched for all these tiny go and rust programs that run and use like 50 mb ram or even less. Running a cluster of 50 containers is really no heavier than a single Xmx1g java process!
        deleted 3y ago
        [deleted]
        pjmlp 3y ago
- vindarel 3y ago
  > bad support for general editors side note: only two years ago we were complaining about the lack of support for VSCode or the Jetbrains suite, now we have working plugins for them: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... in addition of Emacs, Vim, Atom/Pulsar (very decent support), Jupyter notebooks, Sublime, Eclipse (simple support), Geany, enhanced terminal REPLs, Lem (multi-language editor built in CL)…
  - aidenn0 3y ago
    > Geany I wrote that support mostly over a weekend, and judging by the lack of bug reports, either my code is flawless (doubtful) or nobody uses it.
  - reikonomusha 3y ago
    People like to cite supposed VS Code support. I tried it. It's buggy and easy to make crash/spin/not respond/etc. even under casual use. Like... single Lisp file development. This is not to mention the absence of necessities such as correct indentation and paredit-like support. The latter we can get by without, but the former has worked in other editors for 30+ years. Don't get me wrong, it's a great start, and I hope it gets polished. But as of 3 months ago, it still doesn't work well, so much so I'd never actually recommend it seriously to someone who wants to learn Lisp. Have you tried using VS Code (or any other editor you mentioned) for any "serious" full-cycle Lisp development before, and do you believe it passes the minimum bar of stable and recommendable to another professional programmer or enthusiastic hobbyist? Do I need to try again?
    - vindarel 3y ago
      +1. No, VS Code is an unusable resource hog for me, I don't think you would gain sthg in trying the plugin again, the last releases were not full of changes. Lem is remarkably featureful and usable for CL development though! Both its ncurses and SDL2 frontends. I only miss a couple keys from Slime: C-c C-y (print the function the cursor is on to the REPL), C-c ~ (sync the REPL with the current package (namespace)), then a better imenu, and that's it. Simple git support is available for power users too 8-)
- Buttons840 3y ago
  What's good about the new garbage collectors? You've only said they're new, but what makes them better? How do they compare to other languages?
  - hayley-patton 3y ago
    One is parallel, using multiple cores to make collection happen faster, which increases GC throughput and shortens GC pauses. The other is concurrent and avoids pauses entirely, though it requires more bookkeeping from the application and might reduce throughput. I joke that the parallel GC is bringing SBCL to 2000s Java. It seems comparable enough to Java's Parallel, though SBCL aims for less space overhead by default, so you need to adjust either GC to have a fair comparison. The concurrent one is based off a collector for SML#, Haskell has a similar low latency "Alligator" collector too. (Disclaimer: I wrote the parallel collector, and I want to be clear that latency and throughput differ here, because someone didn't before.)
  - aidenn0 3y ago
    SBCL's collector is inherited from cmucl, and it was an excellent collector at the turn of the century. However, it is very of-its-time in two major ways: 1. It is optimized for throughput over pause-times 2. It is non-parallel
- medo-bear 3y ago
  I think common lispers should just accept that they are lone wolf programmers and get on with our lonely lives. Jokes asside, I dont think energy should be spent on editor support. Too much work and little to gain. Instead what needs to be done is to study the so many great libraries and writing the damn documentation (and make it fun). Documentation problem is THE low hanging fruit toward improving the cl ecosystem and attracting new loners. I think once people get the confidence to read and write lisp codebases are much easier to digest than other languages. Which I think is partly responsible for the crap doc situation. But if you think about it this also makes lisp in some sense the perfect open source language. Kudos to things like the cookbook tho !
  - tmtvl 3y ago
    Oh man, look up switch in the Alexandria docs, I really need to sit down and fix that. The documentation culture is the one thing I miss from Perl when I go to... well, any other language. Considering CL has DESCRIBE it's really something we need to get serious about.
  - tnecniv 3y ago
    I used to hang out in an IRC channel, and the big CL proponent there was a Norwegian that would disappear for long periods and go boat / hang out in the woods on his own. Apparently those are common hobbies in Scandinavia but it also makes a lot of sense for a CL lover in hindsight.
  - Jach 3y ago
    JavaDoc has also traditionally been pretty good, and Java's idioms let there be rich doc in the source comments that gets turned into nice HTML. Every so often someone tries to make something similar for Lisp, with mixed results. (The one I remember most recently is https://quickref.common-lisp.net/index-per-library.html https://quickref.common-lisp.net/index-per-library.html but I pretty much never visit it, it's not helpful to me.) It also doesn't help that every project might do something different. (There's also multiple types of docs for different audiences in different contexts, but that's a separate common issue for any language and team.) For a lot of the commonly used libraries, the doc is sufficiently decent, though sometimes unintuitive to find. For core stuff I like the hyperspec as much as the next lisper (and opening it on a symbol is just ,h for me) but there's also http://clqr.boundp.org/ http://clqr.boundp.org/ that not everyone knows about, it's a great little reference to have printed out at my desk. And there's situations like how part of pretty much every Lisp, available through ASDF, is UIOP, a great little portability library. Its doc is at https://asdf.common-lisp.dev/uiop.html https://asdf.common-lisp.dev/uiop.html and it originates in the source repo from a Lisp script taking doc info from the source and applying a .texinfo template to it. Pretty bespoke. But this is also just part of the cost/benefit of CL: it's very unopinionated, unlike say Java or Clojure, and so lets individuals and teams do what they want which naturally isn't going to be the same worldwide. I like certain doc (especially at least one example of using the thing) in repo README files, others don't, nothing forces one way or the other. Once the confidence for Lisp is there though, you're right that it's not a big deal. It's very nice to jump-to-source for everything, including SBCL internals, and modify things even. I can fix some bugs in a dependency library, right now, without having to file an issue/pull request to the library maintainer and waiting for a new release, and that modification can even live in my source tree in the interim as just a bit of code that runs after loading the main library and then redefines one of its functions or whatever. I disagree that any effort needs to be made on attracting lone wolves, less even than trying to make editor support better for beginners; the loners will come on their own in time. Not because CL can only be used by loners (million+ lines of code projects made by teams demonstrate otherwise), but because it's a very good multiplier for that situation.
- hayley-patton 3y ago
  > One of them is a parallel collector written by a university student (!!) which blows my mind. I didn't let schooling interfere with my education.
  - reikonomusha 3y ago
    (Non-obvious context: hayley-patton is the one who wrote the new parallel GC.)
- ilc 3y ago
  Do any of these come close to Genera? That is an amazing system, that even now, could probably hang with the best of them. :/
  - pjmlp 3y ago
    If you want that kind of experience, only commercial Lisps come close to it.
- leoh 3y ago
  Off-topic, but OCaml’s reputation as being good for language design afaict is quite undeserved. I tried using it for a while for several language design exercises, and put it aside. Late last year I picked up Racket and it was radically better. Usage by a hedge fund does not for a impressive language make; nor do decades old accolades.
  - pjmlp 3y ago
    Any ML[0] derived language really, not only OCaml. [0] - https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)
- pjmlp 3y ago
  Missed out Lisp Works and Allegro Common Lisp.
Blackthorn 3y ago
> By embracing Common Lisp over Clojure and the JVM, we’re not only choosing a powerful programming language but also making a greener choice for the environment. My eyes just rolled so far back in my head I can see my skull.
- dang 3y ago
  "Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - bcrosby95 3y ago
    Half the article and a large part of the video is about this. It's not a throwaway sentence or minor point.
    - pvg 3y ago
      The point is about not getting provoked (or at least, not writing tedious things about how provoked you got in HN threads), not the size of the alleged provocation.
    - ryanobjc 3y ago
      [flagged]
  - Blackthorn 3y ago
    The video is a major part about this very point. This isn't some minor little bit, they clearly think this is some major advantage that Common Lisp has, which is ridiculous.
    - CyberDildonics 3y ago
      It really is a bizarre claim to make, I'm glad you said something.
    - 3y ago
harperlee 3y ago
Interestingly it seems that there was no (extended?) mention of Common Lisp on the JVM: Armed Bear Common Lisp. It is not central to the argument, but if one were to decide to migrate from clojure to common lisp, I'd say that one low risk path would be to first validate that you are capable of working with common lisp, and only then start preparing to forego / replace all of your dependencies, which is one of the strong parts of clojure: the ability to leverage everything under the sun that exists in the java / jvm world.
- vindarel 3y ago
  I also hear good things about LispWork's Java interop (commercial).
- aidenn0 3y ago
  Last time I looked into it, ABCL was less performant than more recent JVM hosted languages. I am far from a JVM expert, but I was told that this is due to most development work on ABCL predating JVM enhancements for dynamism. There is also FOIL, which runs JVM (or CLR) in a separate process and provides a bridge for calling into JVM from lisp. It was written by Rich Hickey (the future author of Clojure), who observed that the reflection overhead was similar in magnitude to the serialization overhead!
whartung 3y ago
Is there a "Common Lisp Electron" thing floating around? The GUI situation of the free lisps is pretty much a non-started for anything portable, just curious if there's a project bundling Common Lisp with a browser window, like Rust Taurus. At this level, there's no reason to fret about download sizes anymore if you're comparing to something like Electron, so no real need to "shake the tree" or really limit the lisp image size. Modern lisps aren't that big compared to most anything else anyway.
- vindarel 3y ago
  I am exploring this atm. Basically once you build your CL web app as one binary, containing the HTML and other static assets, it is straightforward to open it in an Electron window. So is it with Tauri, Neutralino or another webview. How to communicate between the CL app and Electron I didn't have a look yet.
- floren 3y ago
  I just wish McCLIM was a little more... ready. I've had some success writing a McCLIM application that works on Linux, but they only support the X backend for now meaning anyone on Windows would have to install an X server. It's a fascinating way to write a GUI, though.
  - rjsw 3y ago
    One of the SBCL developers wrote a McCLIM backend that generated HTML, had been meaning to ask what state it was in.
    - andsoitis 3y ago
      Did you find out from them?
- jinwoo68 3y ago
  See https://github.com/rabbibotton/clog https://github.com/rabbibotton/clog.
- 3y ago
behnamoh 3y ago
> our planet and the technology we use. By embracing Common Lisp over Clojure and the JVM, we’re not only choosing a powerful programming language but also making a greener choice for the environment. Wait what?! When was the last time programmers chose a language because it was "green"? What does it even mean for a language to be "greener" than the others?
- packetlost 3y ago
  Presumably execution efficiency, but tbh I don't think I've ever seen any compelling numbers. The inefficiencies from extra human time would likely offset any potential gains from the pennies you'd save on CPU costs.
  - behnamoh 3y ago
    > Presumably execution efficiency, ... Yeah, in that case Assembly/C is the greenest language but should we switch to them? > The inefficiencies from extra human time would likely offset any potential gains from the pennies you'd save on CPU costs. I'm not sure I follow what you mean here.
    - kazinator 3y ago
      > Yeah, in that case Assembly/C is the greenest language but should we switch to them? We've not switched away.
    - packetlost 3y ago
      The electricity gains to be had are likely very small. Minuscule, even. Humans are not ecologically neutral, we consume food that has environmental impacts. Depending on diet and other lifestyle (physical activity, for example) factor into a humans ecological impact. By increasing the amount of time a human spends on something, you proportionally increase the ecological impact of the task the human is performing. The idea is that duplicating or redoing work may be more costly in aggregate, but absolute terms to the environment than the small offset in energy to be had by making the code more efficient. The point isn't about the absolute numbers, it's just trying to illustrate that the numbers are so small that it might as well be a rounding error unless you're talking about industry or society-levels of impact, which Clojure does not really have.
packetlost 3y ago
To me, the most compelling aspect of Clojure is it's very well designed standard library and ecosystem access via Java. Pretty much everything else is a negative. Even then, the ecosystem is a Faustian bargain.
- wk_end 3y ago
  Can you elaborate? As an outsider, most of the time I hear people say some variation on "Clojure would be great but I stay away because of Java".
  - shrimp_emoji 3y ago
    That was what drove me away. The bloat of the JVM, and the implication of Java down the road, made me nauseous.
    - gorjusborg 3y ago
      Extreme dislike of the JVM/Java always makes me curious. What languages do you work with that would make Java so painful to stoop to?
  - packetlost 3y ago
    Clojure has a pretty well designed standard library and makes (IMO) a lot of good tradeoff decisions for many kinds of development. That stigma round Java is kind of exactly my point about the Faustian bargain. You get access to the Java ecosystem but pay the cost of being tied to the Java ecosystem in some capacity. Now, I think the JVM is actually really good. Yes, it's a bit "chunky" (slow startup times, not very ergonomic UX), but it's very performant and it runs pretty much everywhere.
- gorjusborg 3y ago
  The immutable persistent data structures are amazing. The STM and concurrency support are great. The interop with java is great, but is also a bit of a curse in that there's a bit too much reliance on java libs rather than people writing high-quality language native ones. The sexp-based collection literals are very convenient, and coupled with the threading macros make writing and reading clojure code very productive and fun. Clojure has a lot going for it. The biggest issue I have with it is the same issue I have with any 'hosted' language. If it doesn't own the runtime, it risks being broken or held-back by changes it has no control over. Clojure is conceptually and syntactically simple, so it probably fares better than other JVM-hosted languages, and the JVM itself has historically been very stable at the bytecode level, but it still a risky thing to require your platform to stay stable for your language ecosystem to survive. I love you Clojure, but I'd rather invest in a language that controls its own destiny.
uticus 3y ago
Time to again link to "The Rise and Fall of Lisp at the Jet Propulsion Lab" (2002) https://flownet.com/gat/jpl-lisp.html https://flownet.com/gat/jpl-lisp.html
onyno 3y ago
Lisp Flavoured Erlang (lfe.io) needs more love, from what I’ve seen and tried with it - it could give clojure a run for its money.
- uxcolumbo 3y ago
  How so? Can you share more details?
  - fredrikholm 3y ago
    I'm guessing that OP is stating that the BEAM is a more preferable VM to that of the JVM, and that they prefer a Lisp over Erlang/Elixir.
- zilti 3y ago
  It's really not hard to give Clojure that... I'm a full-time Clojure dev, but also use Scheme a lot, and while some Clojure features are great (mainly the STM), in a lot of cases the terribleness of certain language features and idioms makes me sigh. Lots of bad decisions have been made.
  - uxcolumbo 3y ago
    You mean lots of bad decision by the Clojure core team? Do you have some examples and what language features are terrible?
    - rokkitmensch 3y ago
      My pain points were the idiom of passing giant wads of data around in an unprincipled untyped fashion, and then rooting through them like a boar for nuts in the forest later. "Write tests!" and "use spec" were not great suggestions at the end of the day.
  - harperlee 3y ago
    > (mainly the STM) Interestingly the clojure community at large does not really value or use it so much. I think even Rich Hickey commented on that at some point.
gibsonf1 3y ago
Our TrinPod Server with conceptual AI and space-time digital twin is all in Common Lisp (and incredibly easy to work with and evolve): https://graphmetrix.com/ https://graphmetrix.com/ I'm not sure if the recursive hierarchical conceptual inference as well as many other things would have been possible without Common Lisp.
BaculumMeumEst 3y ago
Is it possible to build SBCL on my quest 3? Would I be able to generate bindings to vulkan and/or openxr with c2ffi or cl-autowrap? It seems like it would be cool to run swank, connect to it with my desktop, and build stuff. Bu
- charcircuit 3y ago
  Yes, you can sideload termux.
  - sea6ear 3y ago
    Sorry for responding late, but I don't think Termux includes SBCL - at least it doesn't on my android devices. But it does include ECL (Embeddable Common Lisp). Apparently, you can compile SBCL using ECL, so if you really want SBCL itself instead of just a Common Lisp implementation, that might be a path to it.
eduction 3y ago
Ya I stopped watching when he said Java was created to counter dot net (at 6:10)
- refset 3y ago
  I think he simply meant that Java was marketed and therefore prospered as a counter to Microsoft's dominance more generally. You're right that .Net (and the CLR) came later in the story ...as a counter to Java.
  - eduction 3y ago
    To be clear the literal text on the slide is “aimed to counter Microsoft’s .NET framework.” He said something similar verbally. Slightly earlier he did discuss the general alliance against Microsoft. I thought it was funny he didn’t mention Netscape as part of the alliance. At the time they were considered far more important than IBM or Oracle for purposes of displacing Microsoft on the consumer side. It’s fine in the grand scheme of things, a younger person who was not there trying to reconstruct what happened and slipping up a bit. But for someone who cares about the details of this sort of history I didn’t want to absorb any similar errors about Common Lisp which I’m genuinely curious to learn about.
  - pjmlp 3y ago
    .NET came out of Microsoft losing the lawsuit on J++, they were already using Java, and COM Runtime (see Ext-VOS paper) was being researched using J++, before the lawsuit came to be. A couple of C# features were born in J++, namely P/Invoke (J/Direct), events (influenced by Delphi before even Anders came to MS), and Windows Forms (WFC).
leoh 3y ago
Racket is just such a better language and community in just about every way. CL has always felt like the C++ of LISPs in terms of both the language and its (imo) snobby community. I’m open to being convinced otherwise, but I generally have about zero desire to touch it. Even regarding performance (claims being questionable and subjective, almost always), the ease with which one can do FFI with racket is meaningful — I would much rather delegate to a lower-level langauge via FFI than muddle around with a pita higher-level language with supposedly better performance semantics. Aside: this is also an argument, for example, for even using python and rust (one of the most depressing things that led me to quitting Google last year was a manager that demanded C++ for performance reasons over Rust despite being off-g3 and it being an utter nightmare to bikeshed about C++ libraries) when someone tells you that you “need” to use C++ for performance.
pjmlp 3y ago
I quickly went through the slides, and this point regardling Sun, IBM and Oracle's java alliance just doesn't make any sense. > "Aimed to counter Microsoft’s .NET framework" First of all the alliace came to be during the 1996 - 2001 timeframe that predated .NET. When Network Computer came out there was no .NET. When Oracle adopted Java into their database ecosystem there was no .NET. When IBM refocused from Smalltalk into Java, there was no .NET. Secondly, .NET was only born with C#, after Sun's lawsuit due to J++ language extensions (J/Direct reborn as P/Invoke, COM interop, WFC reborn as Windows Forms, events). Had it not been for the lawsuit, the updated COM Runtime being researched would have most likely used J++, as shown on the Ext-VOS paper. Also 20 years later, Microsfot saw they had to embrace Java on Azure, and they are now an OpenJDK contributor with their own distribution, talk about strange ironies.
- refset 3y ago
  I replied with this already to another sibling comment raising the same issue: > I think he simply meant that Java was marketed and therefore prospered as a counter to Microsoft's dominance more generally. i.e. ".NET" being used casually (and incorrectly) as a catch-all for anything Microsoft was doing in this space roughly around that period ...possibly suggests there's been an anti-M$ bias!
  - pjmlp 3y ago
    Yeah, however that is how those that weren't there to live through it get the false idea how things actually played out. Windows hegemony should have been used instead.
    - refset 3y ago
      > Windows hegemony :chefs-kiss:
rony989 3y ago
[dead]

183 points by joaogui1 3y ago

deleted 3y ago

[deleted]

Common Lisp has bad marketing (even OCaml has Twitch streamers and "influencers" now), and bad support for general editors, both of which make it a non-starter for most curious people who have an afternoon to try something. But behind all that is magnificent activity for those who got over the initial potential energy barrier. Just to give some examples: 1. SBCL, the most popular open source implementation of Lisp, is seeing potentially two new garbage collectors, one of which is merged and open to beta testing. One of them is a parallel collector written by a university student (!!) which blows my mind. 2. SBCL has better and better support for deploying Lisp as a C-compatible shared library, using SBCL-LIBRARIAN. It makes it play nicer with other applications in C and Python, without the baggage of process wrangling and thick RPC (IPC/servers, serialization, ...). 3. Coalton is another exciting development that allows a Haskell type system and "Lisp-1" functional programming in Common Lisp. That means type classes (or traits), something Lisp hasn't really had a proper notion of, and full type inference. Persistent sequences based off of RRB-trees were recently merged [1], and interestingly, they're implemented purely in Coalton [2]. That means Clojure-like seqs. It's interesting to see users of Lisp generating the above ideas and libraries, not a special in-group of committees, "official" developers, etc. [1] https://coalton-lang.github.io/reference/#seq-type https://coalton-lang.github.io/reference/#seq-type [2] https://github.com/coalton-lang/coalton/blob/main/library/seq.lisp https://github.com/coalton-lang/coalton/blob/main/library/se...

posix_monad 3y ago
Isn't Clojure the most mainstream Lisp at this point?
- reikonomusha 3y ago
  I'd say so, but for many, it's "dead on arrival" for a variety of reasons: Java-centric, unabashedly dynamically typed (favoring instead a slightly more eccentric way of enforcing contracts), etc. Unfortunately, a lot of Scheme and Common Lisp people don't like Clojure a whole lot because it gave up on a variety of things that group has treasured.
  - 7thaccount 3y ago
    It also assumes significant Java knowledge, so I kept finding myself at a dead end where it assumes I know the Java library way to do something and can just call it. I tried Clojure for the Brave and True and Living Clojure. I kept thinking that I wasn't getting anything I couldn't already do in Python (at least for my uses), but there's a lot of baggage like emacs + cider...etc.
    - ryanobjc 3y ago
      The gap between the clojure libs and the java libs and actually calling java is a jarring experience and really isn't a plus. While in theory the java interop is a selling point, if you don't need that it ends up being extra syntactical complexity. Now I haven't coded extensively in clojure, so a lot of it stylistic unfamiliarity. It does hold back people from adopting clojure. One reason why I'm excited never to use the JVM again is the huge memory footprint it uses. The best practices for production java is to figure out how much ram your process will need max under normal (not leaking) usage... and set both max and min ram to that (Xmx and Xms). It's a real hog on ram, and when running under clustered tools like k8 with can do memory overcommits it really reduces your flexibilty. I'm super psyched for all these tiny go and rust programs that run and use like 50 mb ram or even less. Running a cluster of 50 containers is really no heavier than a single Xmx1g java process!
      - deleted 3y ago
        [deleted]
      - pjmlp 3y ago
vindarel 3y ago
> bad support for general editors side note: only two years ago we were complaining about the lack of support for VSCode or the Jetbrains suite, now we have working plugins for them: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... in addition of Emacs, Vim, Atom/Pulsar (very decent support), Jupyter notebooks, Sublime, Eclipse (simple support), Geany, enhanced terminal REPLs, Lem (multi-language editor built in CL)…
- aidenn0 3y ago
  > Geany I wrote that support mostly over a weekend, and judging by the lack of bug reports, either my code is flawless (doubtful) or nobody uses it.
- reikonomusha 3y ago
  People like to cite supposed VS Code support. I tried it. It's buggy and easy to make crash/spin/not respond/etc. even under casual use. Like... single Lisp file development. This is not to mention the absence of necessities such as correct indentation and paredit-like support. The latter we can get by without, but the former has worked in other editors for 30+ years. Don't get me wrong, it's a great start, and I hope it gets polished. But as of 3 months ago, it still doesn't work well, so much so I'd never actually recommend it seriously to someone who wants to learn Lisp. Have you tried using VS Code (or any other editor you mentioned) for any "serious" full-cycle Lisp development before, and do you believe it passes the minimum bar of stable and recommendable to another professional programmer or enthusiastic hobbyist? Do I need to try again?
  - vindarel 3y ago
    +1. No, VS Code is an unusable resource hog for me, I don't think you would gain sthg in trying the plugin again, the last releases were not full of changes. Lem is remarkably featureful and usable for CL development though! Both its ncurses and SDL2 frontends. I only miss a couple keys from Slime: C-c C-y (print the function the cursor is on to the REPL), C-c ~ (sync the REPL with the current package (namespace)), then a better imenu, and that's it. Simple git support is available for power users too 8-)
Buttons840 3y ago
What's good about the new garbage collectors? You've only said they're new, but what makes them better? How do they compare to other languages?
- hayley-patton 3y ago
  One is parallel, using multiple cores to make collection happen faster, which increases GC throughput and shortens GC pauses. The other is concurrent and avoids pauses entirely, though it requires more bookkeeping from the application and might reduce throughput. I joke that the parallel GC is bringing SBCL to 2000s Java. It seems comparable enough to Java's Parallel, though SBCL aims for less space overhead by default, so you need to adjust either GC to have a fair comparison. The concurrent one is based off a collector for SML#, Haskell has a similar low latency "Alligator" collector too. (Disclaimer: I wrote the parallel collector, and I want to be clear that latency and throughput differ here, because someone didn't before.)
- aidenn0 3y ago
  SBCL's collector is inherited from cmucl, and it was an excellent collector at the turn of the century. However, it is very of-its-time in two major ways: 1. It is optimized for throughput over pause-times 2. It is non-parallel
medo-bear 3y ago
I think common lispers should just accept that they are lone wolf programmers and get on with our lonely lives. Jokes asside, I dont think energy should be spent on editor support. Too much work and little to gain. Instead what needs to be done is to study the so many great libraries and writing the damn documentation (and make it fun). Documentation problem is THE low hanging fruit toward improving the cl ecosystem and attracting new loners. I think once people get the confidence to read and write lisp codebases are much easier to digest than other languages. Which I think is partly responsible for the crap doc situation. But if you think about it this also makes lisp in some sense the perfect open source language. Kudos to things like the cookbook tho !
- tmtvl 3y ago
  Oh man, look up switch in the Alexandria docs, I really need to sit down and fix that. The documentation culture is the one thing I miss from Perl when I go to... well, any other language. Considering CL has DESCRIBE it's really something we need to get serious about.
- tnecniv 3y ago
  I used to hang out in an IRC channel, and the big CL proponent there was a Norwegian that would disappear for long periods and go boat / hang out in the woods on his own. Apparently those are common hobbies in Scandinavia but it also makes a lot of sense for a CL lover in hindsight.
- Jach 3y ago
  JavaDoc has also traditionally been pretty good, and Java's idioms let there be rich doc in the source comments that gets turned into nice HTML. Every so often someone tries to make something similar for Lisp, with mixed results. (The one I remember most recently is https://quickref.common-lisp.net/index-per-library.html https://quickref.common-lisp.net/index-per-library.html but I pretty much never visit it, it's not helpful to me.) It also doesn't help that every project might do something different. (There's also multiple types of docs for different audiences in different contexts, but that's a separate common issue for any language and team.) For a lot of the commonly used libraries, the doc is sufficiently decent, though sometimes unintuitive to find. For core stuff I like the hyperspec as much as the next lisper (and opening it on a symbol is just ,h for me) but there's also http://clqr.boundp.org/ http://clqr.boundp.org/ that not everyone knows about, it's a great little reference to have printed out at my desk. And there's situations like how part of pretty much every Lisp, available through ASDF, is UIOP, a great little portability library. Its doc is at https://asdf.common-lisp.dev/uiop.html https://asdf.common-lisp.dev/uiop.html and it originates in the source repo from a Lisp script taking doc info from the source and applying a .texinfo template to it. Pretty bespoke. But this is also just part of the cost/benefit of CL: it's very unopinionated, unlike say Java or Clojure, and so lets individuals and teams do what they want which naturally isn't going to be the same worldwide. I like certain doc (especially at least one example of using the thing) in repo README files, others don't, nothing forces one way or the other. Once the confidence for Lisp is there though, you're right that it's not a big deal. It's very nice to jump-to-source for everything, including SBCL internals, and modify things even. I can fix some bugs in a dependency library, right now, without having to file an issue/pull request to the library maintainer and waiting for a new release, and that modification can even live in my source tree in the interim as just a bit of code that runs after loading the main library and then redefines one of its functions or whatever. I disagree that any effort needs to be made on attracting lone wolves, less even than trying to make editor support better for beginners; the loners will come on their own in time. Not because CL can only be used by loners (million+ lines of code projects made by teams demonstrate otherwise), but because it's a very good multiplier for that situation.
hayley-patton 3y ago
> One of them is a parallel collector written by a university student (!!) which blows my mind. I didn't let schooling interfere with my education.
- reikonomusha 3y ago
  (Non-obvious context: hayley-patton is the one who wrote the new parallel GC.)
ilc 3y ago
Do any of these come close to Genera? That is an amazing system, that even now, could probably hang with the best of them. :/
- pjmlp 3y ago
  If you want that kind of experience, only commercial Lisps come close to it.
leoh 3y ago
Off-topic, but OCaml’s reputation as being good for language design afaict is quite undeserved. I tried using it for a while for several language design exercises, and put it aside. Late last year I picked up Racket and it was radically better. Usage by a hedge fund does not for a impressive language make; nor do decades old accolades.
- pjmlp 3y ago
  Any ML[0] derived language really, not only OCaml. [0] - https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)
pjmlp 3y ago
Missed out Lisp Works and Allegro Common Lisp.

Blackthorn 3y ago

> By embracing Common Lisp over Clojure and the JVM, we’re not only choosing a powerful programming language but also making a greener choice for the environment. My eyes just rolled so far back in my head I can see my skull.

dang 3y ago
"Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- bcrosby95 3y ago
  Half the article and a large part of the video is about this. It's not a throwaway sentence or minor point.
  - pvg 3y ago
    The point is about not getting provoked (or at least, not writing tedious things about how provoked you got in HN threads), not the size of the alleged provocation.
  - ryanobjc 3y ago
    [flagged]
- Blackthorn 3y ago
  The video is a major part about this very point. This isn't some minor little bit, they clearly think this is some major advantage that Common Lisp has, which is ridiculous.
  - CyberDildonics 3y ago
    It really is a bizarre claim to make, I'm glad you said something.
  - 3y ago

harperlee 3y ago

Interestingly it seems that there was no (extended?) mention of Common Lisp on the JVM: Armed Bear Common Lisp. It is not central to the argument, but if one were to decide to migrate from clojure to common lisp, I'd say that one low risk path would be to first validate that you are capable of working with common lisp, and only then start preparing to forego / replace all of your dependencies, which is one of the strong parts of clojure: the ability to leverage everything under the sun that exists in the java / jvm world.

vindarel 3y ago
I also hear good things about LispWork's Java interop (commercial).
aidenn0 3y ago
Last time I looked into it, ABCL was less performant than more recent JVM hosted languages. I am far from a JVM expert, but I was told that this is due to most development work on ABCL predating JVM enhancements for dynamism. There is also FOIL, which runs JVM (or CLR) in a separate process and provides a bridge for calling into JVM from lisp. It was written by Rich Hickey (the future author of Clojure), who observed that the reflection overhead was similar in magnitude to the serialization overhead!

whartung 3y ago

Is there a "Common Lisp Electron" thing floating around? The GUI situation of the free lisps is pretty much a non-started for anything portable, just curious if there's a project bundling Common Lisp with a browser window, like Rust Taurus. At this level, there's no reason to fret about download sizes anymore if you're comparing to something like Electron, so no real need to "shake the tree" or really limit the lisp image size. Modern lisps aren't that big compared to most anything else anyway.

vindarel 3y ago
I am exploring this atm. Basically once you build your CL web app as one binary, containing the HTML and other static assets, it is straightforward to open it in an Electron window. So is it with Tauri, Neutralino or another webview. How to communicate between the CL app and Electron I didn't have a look yet.
floren 3y ago
I just wish McCLIM was a little more... ready. I've had some success writing a McCLIM application that works on Linux, but they only support the X backend for now meaning anyone on Windows would have to install an X server. It's a fascinating way to write a GUI, though.
- rjsw 3y ago
  One of the SBCL developers wrote a McCLIM backend that generated HTML, had been meaning to ask what state it was in.
  - andsoitis 3y ago
    Did you find out from them?
jinwoo68 3y ago
See https://github.com/rabbibotton/clog https://github.com/rabbibotton/clog.
3y ago

behnamoh 3y ago

> our planet and the technology we use. By embracing Common Lisp over Clojure and the JVM, we’re not only choosing a powerful programming language but also making a greener choice for the environment. Wait what?! When was the last time programmers chose a language because it was "green"? What does it even mean for a language to be "greener" than the others?

packetlost 3y ago
Presumably execution efficiency, but tbh I don't think I've ever seen any compelling numbers. The inefficiencies from extra human time would likely offset any potential gains from the pennies you'd save on CPU costs.
- behnamoh 3y ago
  > Presumably execution efficiency, ... Yeah, in that case Assembly/C is the greenest language but should we switch to them? > The inefficiencies from extra human time would likely offset any potential gains from the pennies you'd save on CPU costs. I'm not sure I follow what you mean here.
  - kazinator 3y ago
    > Yeah, in that case Assembly/C is the greenest language but should we switch to them? We've not switched away.
  - packetlost 3y ago
    The electricity gains to be had are likely very small. Minuscule, even. Humans are not ecologically neutral, we consume food that has environmental impacts. Depending on diet and other lifestyle (physical activity, for example) factor into a humans ecological impact. By increasing the amount of time a human spends on something, you proportionally increase the ecological impact of the task the human is performing. The idea is that duplicating or redoing work may be more costly in aggregate, but absolute terms to the environment than the small offset in energy to be had by making the code more efficient. The point isn't about the absolute numbers, it's just trying to illustrate that the numbers are so small that it might as well be a rounding error unless you're talking about industry or society-levels of impact, which Clojure does not really have.

packetlost 3y ago

To me, the most compelling aspect of Clojure is it's very well designed standard library and ecosystem access via Java. Pretty much everything else is a negative. Even then, the ecosystem is a Faustian bargain.

wk_end 3y ago
Can you elaborate? As an outsider, most of the time I hear people say some variation on "Clojure would be great but I stay away because of Java".
- shrimp_emoji 3y ago
  That was what drove me away. The bloat of the JVM, and the implication of Java down the road, made me nauseous.
  - gorjusborg 3y ago
    Extreme dislike of the JVM/Java always makes me curious. What languages do you work with that would make Java so painful to stoop to?
- packetlost 3y ago
  Clojure has a pretty well designed standard library and makes (IMO) a lot of good tradeoff decisions for many kinds of development. That stigma round Java is kind of exactly my point about the Faustian bargain. You get access to the Java ecosystem but pay the cost of being tied to the Java ecosystem in some capacity. Now, I think the JVM is actually really good. Yes, it's a bit "chunky" (slow startup times, not very ergonomic UX), but it's very performant and it runs pretty much everywhere.
gorjusborg 3y ago
The immutable persistent data structures are amazing. The STM and concurrency support are great. The interop with java is great, but is also a bit of a curse in that there's a bit too much reliance on java libs rather than people writing high-quality language native ones. The sexp-based collection literals are very convenient, and coupled with the threading macros make writing and reading clojure code very productive and fun. Clojure has a lot going for it. The biggest issue I have with it is the same issue I have with any 'hosted' language. If it doesn't own the runtime, it risks being broken or held-back by changes it has no control over. Clojure is conceptually and syntactically simple, so it probably fares better than other JVM-hosted languages, and the JVM itself has historically been very stable at the bytecode level, but it still a risky thing to require your platform to stay stable for your language ecosystem to survive. I love you Clojure, but I'd rather invest in a language that controls its own destiny.

uticus 3y ago

Time to again link to "The Rise and Fall of Lisp at the Jet Propulsion Lab" (2002) https://flownet.com/gat/jpl-lisp.html https://flownet.com/gat/jpl-lisp.html

onyno 3y ago

Lisp Flavoured Erlang (lfe.io) needs more love, from what I’ve seen and tried with it - it could give clojure a run for its money.

uxcolumbo 3y ago
How so? Can you share more details?
- fredrikholm 3y ago
  I'm guessing that OP is stating that the BEAM is a more preferable VM to that of the JVM, and that they prefer a Lisp over Erlang/Elixir.
zilti 3y ago
It's really not hard to give Clojure that... I'm a full-time Clojure dev, but also use Scheme a lot, and while some Clojure features are great (mainly the STM), in a lot of cases the terribleness of certain language features and idioms makes me sigh. Lots of bad decisions have been made.
- uxcolumbo 3y ago
  You mean lots of bad decision by the Clojure core team? Do you have some examples and what language features are terrible?
  - rokkitmensch 3y ago
    My pain points were the idiom of passing giant wads of data around in an unprincipled untyped fashion, and then rooting through them like a boar for nuts in the forest later. "Write tests!" and "use spec" were not great suggestions at the end of the day.
- harperlee 3y ago
  > (mainly the STM) Interestingly the clojure community at large does not really value or use it so much. I think even Rich Hickey commented on that at some point.

gibsonf1 3y ago

Our TrinPod Server with conceptual AI and space-time digital twin is all in Common Lisp (and incredibly easy to work with and evolve): https://graphmetrix.com/ https://graphmetrix.com/ I'm not sure if the recursive hierarchical conceptual inference as well as many other things would have been possible without Common Lisp.

BaculumMeumEst 3y ago

Is it possible to build SBCL on my quest 3? Would I be able to generate bindings to vulkan and/or openxr with c2ffi or cl-autowrap? It seems like it would be cool to run swank, connect to it with my desktop, and build stuff. Bu

charcircuit 3y ago
Yes, you can sideload termux.
- sea6ear 3y ago
  Sorry for responding late, but I don't think Termux includes SBCL - at least it doesn't on my android devices. But it does include ECL (Embeddable Common Lisp). Apparently, you can compile SBCL using ECL, so if you really want SBCL itself instead of just a Common Lisp implementation, that might be a path to it.

eduction 3y ago

Ya I stopped watching when he said Java was created to counter dot net (at 6:10)

refset 3y ago
I think he simply meant that Java was marketed and therefore prospered as a counter to Microsoft's dominance more generally. You're right that .Net (and the CLR) came later in the story ...as a counter to Java.
- eduction 3y ago
  To be clear the literal text on the slide is “aimed to counter Microsoft’s .NET framework.” He said something similar verbally. Slightly earlier he did discuss the general alliance against Microsoft. I thought it was funny he didn’t mention Netscape as part of the alliance. At the time they were considered far more important than IBM or Oracle for purposes of displacing Microsoft on the consumer side. It’s fine in the grand scheme of things, a younger person who was not there trying to reconstruct what happened and slipping up a bit. But for someone who cares about the details of this sort of history I didn’t want to absorb any similar errors about Common Lisp which I’m genuinely curious to learn about.
- pjmlp 3y ago
  .NET came out of Microsoft losing the lawsuit on J++, they were already using Java, and COM Runtime (see Ext-VOS paper) was being researched using J++, before the lawsuit came to be. A couple of C# features were born in J++, namely P/Invoke (J/Direct), events (influenced by Delphi before even Anders came to MS), and Windows Forms (WFC).

leoh 3y ago

Racket is just such a better language and community in just about every way. CL has always felt like the C++ of LISPs in terms of both the language and its (imo) snobby community. I’m open to being convinced otherwise, but I generally have about zero desire to touch it. Even regarding performance (claims being questionable and subjective, almost always), the ease with which one can do FFI with racket is meaningful — I would much rather delegate to a lower-level langauge via FFI than muddle around with a pita higher-level language with supposedly better performance semantics. Aside: this is also an argument, for example, for even using python and rust (one of the most depressing things that led me to quitting Google last year was a manager that demanded C++ for performance reasons over Rust despite being off-g3 and it being an utter nightmare to bikeshed about C++ libraries) when someone tells you that you “need” to use C++ for performance.

pjmlp 3y ago

I quickly went through the slides, and this point regardling Sun, IBM and Oracle's java alliance just doesn't make any sense. > "Aimed to counter Microsoft’s .NET framework" First of all the alliace came to be during the 1996 - 2001 timeframe that predated .NET. When Network Computer came out there was no .NET. When Oracle adopted Java into their database ecosystem there was no .NET. When IBM refocused from Smalltalk into Java, there was no .NET. Secondly, .NET was only born with C#, after Sun's lawsuit due to J++ language extensions (J/Direct reborn as P/Invoke, COM interop, WFC reborn as Windows Forms, events). Had it not been for the lawsuit, the updated COM Runtime being researched would have most likely used J++, as shown on the Ext-VOS paper. Also 20 years later, Microsfot saw they had to embrace Java on Azure, and they are now an OpenJDK contributor with their own distribution, talk about strange ironies.

refset 3y ago
I replied with this already to another sibling comment raising the same issue: > I think he simply meant that Java was marketed and therefore prospered as a counter to Microsoft's dominance more generally. i.e. ".NET" being used casually (and incorrectly) as a catch-all for anything Microsoft was doing in this space roughly around that period ...possibly suggests there's been an anti-M$ bias!
- pjmlp 3y ago
  Yeah, however that is how those that weren't there to live through it get the false idea how things actually played out. Windows hegemony should have been used instead.
  - refset 3y ago
    > Windows hegemony :chefs-kiss:

rony989 3y ago

[dead]