13 ms·

State of the Common Lisp ecosystem, 2020

311 points by lelf 6y ago

yawn 6y ago
I like this as a general idea for users (and potential users) of programming languages. See also Sergey Tihon's tireless efforts with F# Weekly: https://sergeytihon.com/category/f-weekly/ https://sergeytihon.com/category/f-weekly/.
waynecochran 6y ago
Some of the happiest days of my programming life was during a brief stint in grad school doing AI programming in Common Lisp (circa 1992). The purity of functional programming and the rapid implementation of algorithm PoC's was pure joy. The pragmatics of life have kept me from using CL since them -- I wish this effort the best success.
wiz21c 6y ago
Interestingly, not much about ML. Surprinsing for lisp which, if I understand correctly, has roots in AI...
- jascii 6y ago
  The focus of "AI" has shifted over time from symbolic processing (something lisps star at) to neural network machine learning, which requires more brute-force power.
  - jefft255 6y ago
    I think the issue isn't "brute force power" (which python doesn't really have compared to CL if you look at the language itself), but rather the quality and completeness of numerical routines and GPU support. Matlab was very popular for early ML because it had the former.
    - hajile 6y ago
      Python is doing the actual lifting with C or Fortran, so I'd say brute force still applies quite a bit.
      - junke 6y ago
        Same for the Lisp libraries which rely on CUDA, OpenBlas, etc.
- pjmlp 6y ago
  The AI of the first Winter had nothing to do with ML, rather expert systems and symbolic processing. Python is starting to look like the Lisp of the second Winter. https://norvig.com/python-lisp.html https://norvig.com/python-lisp.html
  - waynecochran 6y ago
    Are we not heading for a 3rd AI Winter? The first being in the 1970's and the second in the 1980's and 1990's (which I experienced)?
    - evgen 6y ago
      I don't think there was a post-70s winter. There was just not enough 'there' to over-hype; it was toy problems that did not even try to masquerade as real solutions other than in sci-fi and popular culture. Luminaries in the field definitely made a name by pumping out speculative paper after speculative paper, but IMHO there was more of an ember waiting to spark than there was a fire consuming all of its fuel. By the late-80s and early-90s you have venture-backed companies, big institutional efforts, grifters who had honed their pitch in academic tenure-track positions prior to moving to richer waters, and the first real claims being made regarding just-around-the-corner deliverables that would change everything. Maybe I am jaded from experiencing that same winter, but from what I recall the prior decades were more consumed with people making broad claims to try to establish intellectual primacy more than making claims about what could be delivered.
      - Jtsummers 6y ago
        The term showed up in the 80s, but there was an earlier (70s) failure in AI. There were a lot of grand ideas and promises, people really did anticipate AI moving much faster in the 60s and early 70s than it did. Since a lot of ideas (both regarding AI and CS in general) were in their infancy, the limits of computers (fundamental limits) weren't yet fully recognized, but also the hardware was itself creating limits (non-fundamental to the field) that weren't escaped until the 80s and 90s. See chess AIs of the 90s finally "solving" the problem, which would've been technically conceivable (how to do it) in the 70s but totally unrealizable (unless, maybe, you hooked every computer of the time together).
- bumbada 6y ago
  I would say AI roots and research are lisp, as 99% of all early research work was done on lisp. Lisp was the language people like Richard Stallman or John McCarthy(the inventor of Lisp) used at MIT AI laboratory: https://en.wikipedia.org/wiki/MIT_Computer_Science_and_Artificial_Intelligence_Laboratory https://en.wikipedia.org/wiki/MIT_Computer_Science_and_Artif... Everybody used Lisp there and young people that learned from the masters learned lisp too. But that was AI 1.0. Then came the AI winter and 2.0 spring with GPUs that were programmed in C dialects and gave incredible levels of raw power. So, as a high level access to low level C code, python was picked by most people.
  - blackrock 6y ago
    It would be great if Python had a PEP to automatically compile down to a binary executable file, and resolve all dependencies for it.
lukego 6y ago
I really appreciate this effort. I'm coming back to Common Lisp after a long absence and I'm very interested in understanding what the most relevant projects are these days. Can be hard with Lisp due to the long history and strong backwards compatibility. I've started using Screamer for the first time today and that was written around 30 years ago...
- stanislavb 6y ago
  I built LibHunt recently, and it could help you (potentially) with discovering relevant lisp projects. i.e. I'm tracking all links posted on Hacker News and Reddit. With that data in place, you can find out the projects people are linking to and their alternatives https://www.libhunt.com/l/common-lisp https://www.libhunt.com/l/common-lisp
Jach 6y ago
Nice write up. A small extra note for the community section, I've really appreciated Planet Lisp's (http://planet.lisp.org/ http://planet.lisp.org/) RSS feed. It aggregates a bunch of other feeds so you can more easily keep track of what's going on in the Lisp world.
vasergen 6y ago
Out of topic, but as somebody who interested in lisp generally, I have a question, from which dialect would you suggest to start? I am a little bit lost. I am considering clojure, racket and common lisp. I am reading at the moment sicp book and do exercises in `racket sicp package` which is again another dialect. After that want to start with something modern. What was you way to lisp?
- tines 6y ago
  To me, the entire point of Lisp, the thing that sets it apart from other languages, is unhygeinic macros. Since that is my view, I can only recommend Common Lisp. CL is the opposite of modern, but just because something is modern doesn't make it good, nor does old make bad.
  - bjoli 6y ago
    As someone who has written a lot of CL and now deals mostly in scheme, why is an unhygienic macro system important? I don't think it matters much, and frankly I think something like vanilla syntax-case isn't hygienic enough. Either I don't want to care about accidentally capturing identifiers (and be very explicit when I do want it - Day like in srgi-72), or I want to have a system where I deal with explicitly (defmacro) Which I am using matters very little.
    - varjag 6y ago
      In a lisp-1 like Scheme it's a lot easier to shoot yourself in the foot with unhygienic macros.
      - bjoli 6y ago
        I don't think that matters. Either you write a macro that is correct that won't break because of unwanted intersection with the place of expansion, or your macro is wrong. Edit: barring code-walking macro of course. Once you start using those, the bets are off. Edit2: of course, I don't think overwriting core forms count either. That is poor bedside manners :)
kras143 6y ago
The best progamming book I have read so far is "On Lisp". Reading that book and coding Lisp for sometime was the best time I spent programming. Unfortunately, the whole thing was purely academic. Thanks for the effort and the information you put together.
- retzkek 6y ago
  Note that PG has made "On Lisp" available for free: http://www.paulgraham.com/onlisptext.html http://www.paulgraham.com/onlisptext.html
  - pronoiac 6y ago
    It looks like someone else found and re-added the diagrams: http://www.lurklurk.org/onlisp/onlisp.html http://www.lurklurk.org/onlisp/onlisp.html
reikonomusha 6y ago
I think this article (of sorts) is definitely helpful for onlookers to Common Lisp, but doesn't provide the full "story" or "feel" of Common Lisp, and I want to offer to HN my own perspective. Disclaimer #1: I've been working professionally as a Common Lisp programmer---not as a contractor!---for the past decade. I have a vested interest in the language and hiring for it. Disclaimer #2: I am going to ignore commercial implementations of Lisp here, which provide very useful and advanced features, like GUI development, a user-friendly IDE, paid support, etc. [1,2] So let's get started. Common Lisp's best feature is that it allows you to be insanely productive at the "raw programmer" level. You can write, edit, and debug code very quickly and incrementally, and end up with safe & performant code. There's a price to pay: currently the best-in-class experience is still Emacs and SLIME (which come nicely packaged here [3]). As an Emacs fan, that's the best news, but to my fellow PyCharm/VSCode/vim users, it's terrible and alienating news. My colleagues who aren't Emacs users managed to learn just enough Emacs to be productive in a week, but they still frequently fired up their editor of choice in times of need. It really is worth underscoring that the Emacs+SLIME experience truly fits Common Lisp development like a glove, and the experience, in my opinion, is better than almost every mainstream editor environment out there. Common Lisp's worst feature is that it feels like just about everything imaginable has a catch. I don't mean "there's no free lunch", I mean that things just plainly don't feel cohesive or "100%" most of the time. To name a few examples: 1. GUIs: If you want to make a traditional, native GUI using open source solutions, you're stuck with really goofy libraries that are non-obvious to get working. As the article points out, you have options. Lisp actually has a renowned framework called CLIM, but I consider the open-source implementation McCLIM [4] currently only principally useful to hobbyists and hackers. 2. Deploying applications: Almost every implementation of Lisp has some way to create an executable. But very important aspects that real people care about in production are missing, inconsistent, or poorly documented. For example, almost no open source implementations of Lisp have first-class support for signing binaries on MacOS. Almost no open source implementations have a "tree shaker" to remove unnecessary cruft from the executable. Almost no open source implementations make building a shared library practical. 3. Libraries: Many libraries don't do even usual things people might want to do. The linear algebra library MAGICL [8], for example, doesn't at the time of writing have a way to solve the matrix equation Ax=B. This isn't due to laziness of the authors or lack of foresight, but rather that it's a library that's just not used by enough people to see regular, high-quality contributions as an open-source project. I'm sure MAGICL solves problems for the authors, but the authors haven't taken it upon themselves to make a general, useful, and quasi-complete library for matrix programming in Lisp. These examples are just examples, maybe not even the top examples. There are many things I wish for Common Lisp, but there are two I think I wish most. First, I wish Common Lisp implementations put in work so that they could play nice with other programming languages. Google [11] recently came out with support for protobufs in Lisp, which is nice, but I feel something deeper is needed. I think Common Lisp implementations supporting building C ABI-compatible shared libraries would be an insanely big step forward; it'd mean that Lisp could feasibly used by every language out there. Right now, the closest we've got is Embeddable Common Lisp, an implementation of Lisp which makes embedding Lisp within C relatively painless, but as usual, it has many catches [12]. The way I've coped is to produce stand-alone command-line applications, or to build servers with HTTP APIs. But it feels icky, especially if you're working with Python programmers who want to `import` stuff and not run servers just to get some code to work. Second, another thing that I constantly hope for in the Lisp world is for more "hyper productive" programmers to join it, or programmers whose livelihood depends on it. Of course, since Lisp is used by hobbyists, you see tons of hobbyist code. To be sure, a lot of this hobbyist code is perfectly fine. Usually it works, but it's just a tad incomplete. However, in my opinion, the worst thing about hobbyist code is that it usually doesn't do something useful. What does "useful" even mean? I won't claim to be able to define this term in a one-size-fits-all fashion, but "useful" to me is about getting practical computing work done. The further away from being concrete the library is, typically the less useful it is. For example, a typical Lisp programmer will have a penchant for writing a domain-specific language for parsing binary files (cool!), will open-source that code (cool!), but then nobody---including the author of said library---will actually use it to, say, write a parser for GIFs [5]. When somebody does come along to write a GIF parser, they're likely not going to use this general binary parsing framework, but hand-roll their own thing. In Lisp, it seems popular to solve meta-problems instead of problems, which is partly due to the fact that Lisp lets you think about problems at very high levels of abstraction using its advanced object system, the meta-object protocol, and macros. (One of my biggest "pet peeve" projects in Lisp, second only to "utility libraries", are documentation generator libraries. As soon as somebody figures out that documentation strings can actually be programmatically queried in Lisp, they invariably write a baroque "generator" that spits out HTML. I've never, not a single time, ever, used a documentation generator for doing real, paid work. I think one Lisp programmer I know uses it nicely is Nicolas Hafner, aka Shinmera, who uses a documentation generator simply to augment his long-form documentation writing. Staple [9] is one example library of his, where you can see some generated documentation at the bottom.) "Useful" also has to do with how a library is consumed. In the Common Lisp, a library like this [6] is typical. It's a bare page (be it on GitHub or otherwise) that provides no examples, no indication of dependencies, etc. Not all libraries are like this, but you run into it frequently enough. The Common Lisp ecosystem lacks a certain "go-getter" philosophy, needed to forge through "boring" work, that some other language ecosystems seem to have. To cherry pick one example, though I don't use it, Zig [7] comes out with interesting stuff all the time that's genuinely useful. Andrew Kelley, its main developer, is putting tons of hours into getting details around deployment right (e.g., cross-compilation). Little about Common Lisp prevents a motivated person from making equally productive-enhancing strides with the language, but I find that either (a) the interest isn't there or (b) the interest is there but the interest is for developing weird, esoteric stuff in Lisp. (My favorite example of a "productive stride" that happened in Lisp is the following. For context, people talk about all the time how difficult it would be to port a Lisp compiler to a new architecture. I myself have clamored for documentation on how to do it with SBCL. But, out of nowhere, some grad student named Charles Zhang came out with a port of SBCL to RISC-V. Not only did he port it, he's maintained it with 100s of new commits, making it more performant and less buggy [10].) Common Lisp is an amazing language purely from a practical point-of-view. As I said, to me, it's bar-none the best and most productive language to use if you want to "sit down and write code". The implementations of Lisp, like SBCL, are marvels. Lisp code, once you write it, will work forever (seriously, decades). The #lisp channel on Freenode is nice and helpful, and there are so many amazing people in the community. In Lisp, it's seamless to inspect assembly code and work with the world's most high-level, meta-object systems all at the same time. But the ecosystem mouthfeel is still off, and Common Lisp would greatly benefit from programmers obsessed with making the language more useful to themselves and others today. [1]: LispWorks: http://www.lispworks.com/ http://www.lispworks.com/ [2]: Allegro CL: https://franz.com/products/allegro-common-lisp/ https://franz.com/products/allegro-common-lisp/ [3]: Portacle: https://portacle.github.io/ https://portacle.github.io/ [4]: McCLIM: https://common-lisp.net/project/mcclim/ https://common-lisp.net/project/mcclim/ [5]: There is a GIF parser though called SKIPPY! https://www.xach.com/lisp/skippy/ https://www.xach.com/lisp/skippy/ [6]: MIDI: http://www.doc.gold.ac.uk/isms/lisp/midi/ http://www.doc.gold.ac.uk/isms/lisp/midi/ [7]: Zig: https://ziglang.org/ https://ziglang.org/ [8]: MAGICL: https://github.com/rigetti/magicl https://github.com/rigetti/magicl [9]: Staple: https://shinmera.github.io/staple/ https://shinmera.github.io/staple/ [10]: Charles Zhang's SBCL commits https://github.com/sbcl/sbcl/commits?author=karlosz https://github.com/sbcl/sbcl/commits?author=karlosz [11]: CL-PROTOBUFS: https://github.com/qitab/cl-protobufs https://github.com/qitab/cl-protobufs [12]: Poorly documented, performance isn't very good, it's maintained by essentially one person, the rituals needed to use ECL-built libraries are more extensive than necessary, build times are insanely slow, ...
pid_0 6y ago
I just don't get the appeal of Lisps. They look so ugly and the syntax seems crazy ((((((((((((((((( by the way
- iainctduncan 6y ago
  tastes differ. I'm a lot more averse to: end end end end or in JS: }); }); }); });
  - pid_0 6y ago
    Yes both are ugly, which is why Python is so great. Go is also nice.
    - iainctduncan 6y ago
      Agreed. Though I'm mostly a scheme and C hacker these days, I did Python professionally for about 13 years, and that is a very nice side effect of the whitespace thing. On the other, Python has no decent equivalent of Lisp's let, and complex or nested Clojures of anonymous functions are butt ugly in Python, so now I'm happy with my parens.
      - deleted 6y ago
        [deleted]
- kazinator 6y ago
  That much stacking of opening parentheses is never seen, only ))))))). Typing )))... is easy; just hold down the ) key to repeat, and watch the cursor jump back and forth due to parenthesis-matching. When it flicks back to the correct target, release, and backspace over any overshot parens.
- noidesto 6y ago
  Look crazy to fresh eyes. I've found it to be a non-issue the more I write lisp code. With structural editors like parinfer, paredit, smartparens, etc. it becomes a whole lot better.
galaxyLogic 6y ago
A question: How does CLOS rate in terms of "functional purity". Or does it matter? The biggest selling point of Haskellers seems to be that Haskell is a "pure" functional language. Are there practical problems caused by mutable data in CLOS?
- reikonomusha 6y ago
  CLOS doesn’t require the use of mutation and in fact has explicit options to make data read-only. So it’s a matter of personal discipline whether you mutate or not, though I’d say it’s entirely idiomatic to mutate.
- aidenn0 6y ago
  I'm not sure I understand the question. You can write CLOS code in a pure-functional manner, or you can choose not to. Generic-functions are, in general, more useful for some types of functional programming than the typical single-dispatch style used by most other languages. Haskell and common lisp are at nearly opposite ends of the spectrum on many design decisions (Haskell is a Lazy, curried, typed language with lots of syntax and custom infix operators; Common Lisp is a (usually) eager, mostly[1] untyped language with little syntax and only prefix operators) 1: I say mostly because CL does have type declarations, but it's not defined how (or even if) the declarations are enforced in the CL standard. SBCL is arguably a typed implementation of CL, but even then, the fact that you can't in any useful manner[2] describe a type that is "A list of items of type X" in CL puts it in strong contrast to Haskell's rich type system. 2: You can use a "satisfies" type, but satisfies type declarations are ignored at compile time, so even in SBCL they are largely just syntax-sugar for assertions.
  - galaxyLogic 6y ago
    I think everybody agrees that immutable data-structures are preferable to mutable ones if it is possible to get by without mutation in practice. In Haskell it seems it is difficult to mutate data, whereas in Lisp not so. If immutability is good then it would seem it is best if you can enforce immutability at the language level. I'm just wondering whether mutability is a downside of Common Lisp?
tmwed 6y ago
One thing that really bugs me about CommonLisp, is that docs for the supposedly popular libraries are often broken, because they relied on a 3rd party service QuickLisp. A great example of this, is the linked “Clack Getting Started Guide” in the article isn’t even referenced in the clack library repo. This guide than proceeds to link to the broken QuickLisp docs. It’s madness, especially for people that WANT to help move this language forward and increase adoption.
- reikonomusha 6y ago
  Do you mean Quickdocs? That was a passion project of someone who decided to stop maintaining it. It’s open source and can regenerate docs to be up-to-date. The author simply decided he doesn’t want to maintain it anymore due to other life/health circumstances. Quicklisp has nothing to do with documentation. That’s a distribution mechanism.
- aidenn0 6y ago
  I wrote the Clack getting started guide. I fixed the broken link you pointed out.
dhab 6y ago
I recently tried learning CL, and was dismayed at the tooling. While Emacs + SLIME seems to be the recommended way to go, yielding great experience; I could not realise that because I could not get SLIME to work with EMACS, and couldn't get any help in resolving it. This was after having it work on a previous macbook. Then changed the laptop, tried installing it and got stuck. Led me to give up learning it at all. I'd like to add better onboarding to the list of things to improve
- heracles 6y ago
  The article does mention Portacle, which is very easy to install on MacOS. I'd recommend you try it to see if there's any trouble.
- vindarel 6y ago
  I agree that was an issue. Now the SLIMA plugin for Atom is very good and getting very close to Slime. The ones for Sublime and VSCode are getting close too. Dandelion for Eclipse allows to get started very easily (but is less complete).
- jnxx 6y ago
  maybe you just need a Linux laptop, like some old Thinkpad with Ubuntu. Install time is 15 Minutes or so. Emacs is included by default.

311 points by lelf 6y ago

yawn 6y ago

I like this as a general idea for users (and potential users) of programming languages. See also Sergey Tihon's tireless efforts with F# Weekly: https://sergeytihon.com/category/f-weekly/ https://sergeytihon.com/category/f-weekly/.

waynecochran 6y ago

Some of the happiest days of my programming life was during a brief stint in grad school doing AI programming in Common Lisp (circa 1992). The purity of functional programming and the rapid implementation of algorithm PoC's was pure joy. The pragmatics of life have kept me from using CL since them -- I wish this effort the best success.

wiz21c 6y ago

Interestingly, not much about ML. Surprinsing for lisp which, if I understand correctly, has roots in AI...

jascii 6y ago
The focus of "AI" has shifted over time from symbolic processing (something lisps star at) to neural network machine learning, which requires more brute-force power.
- jefft255 6y ago
  I think the issue isn't "brute force power" (which python doesn't really have compared to CL if you look at the language itself), but rather the quality and completeness of numerical routines and GPU support. Matlab was very popular for early ML because it had the former.
  - hajile 6y ago
    Python is doing the actual lifting with C or Fortran, so I'd say brute force still applies quite a bit.
    - junke 6y ago
      Same for the Lisp libraries which rely on CUDA, OpenBlas, etc.
pjmlp 6y ago
The AI of the first Winter had nothing to do with ML, rather expert systems and symbolic processing. Python is starting to look like the Lisp of the second Winter. https://norvig.com/python-lisp.html https://norvig.com/python-lisp.html
- waynecochran 6y ago
  Are we not heading for a 3rd AI Winter? The first being in the 1970's and the second in the 1980's and 1990's (which I experienced)?
  - evgen 6y ago
    I don't think there was a post-70s winter. There was just not enough 'there' to over-hype; it was toy problems that did not even try to masquerade as real solutions other than in sci-fi and popular culture. Luminaries in the field definitely made a name by pumping out speculative paper after speculative paper, but IMHO there was more of an ember waiting to spark than there was a fire consuming all of its fuel. By the late-80s and early-90s you have venture-backed companies, big institutional efforts, grifters who had honed their pitch in academic tenure-track positions prior to moving to richer waters, and the first real claims being made regarding just-around-the-corner deliverables that would change everything. Maybe I am jaded from experiencing that same winter, but from what I recall the prior decades were more consumed with people making broad claims to try to establish intellectual primacy more than making claims about what could be delivered.
    - Jtsummers 6y ago
      The term showed up in the 80s, but there was an earlier (70s) failure in AI. There were a lot of grand ideas and promises, people really did anticipate AI moving much faster in the 60s and early 70s than it did. Since a lot of ideas (both regarding AI and CS in general) were in their infancy, the limits of computers (fundamental limits) weren't yet fully recognized, but also the hardware was itself creating limits (non-fundamental to the field) that weren't escaped until the 80s and 90s. See chess AIs of the 90s finally "solving" the problem, which would've been technically conceivable (how to do it) in the 70s but totally unrealizable (unless, maybe, you hooked every computer of the time together).
bumbada 6y ago
I would say AI roots and research are lisp, as 99% of all early research work was done on lisp. Lisp was the language people like Richard Stallman or John McCarthy(the inventor of Lisp) used at MIT AI laboratory: https://en.wikipedia.org/wiki/MIT_Computer_Science_and_Artificial_Intelligence_Laboratory https://en.wikipedia.org/wiki/MIT_Computer_Science_and_Artif... Everybody used Lisp there and young people that learned from the masters learned lisp too. But that was AI 1.0. Then came the AI winter and 2.0 spring with GPUs that were programmed in C dialects and gave incredible levels of raw power. So, as a high level access to low level C code, python was picked by most people.
- blackrock 6y ago
  It would be great if Python had a PEP to automatically compile down to a binary executable file, and resolve all dependencies for it.

lukego 6y ago

I really appreciate this effort. I'm coming back to Common Lisp after a long absence and I'm very interested in understanding what the most relevant projects are these days. Can be hard with Lisp due to the long history and strong backwards compatibility. I've started using Screamer for the first time today and that was written around 30 years ago...

stanislavb 6y ago
I built LibHunt recently, and it could help you (potentially) with discovering relevant lisp projects. i.e. I'm tracking all links posted on Hacker News and Reddit. With that data in place, you can find out the projects people are linking to and their alternatives https://www.libhunt.com/l/common-lisp https://www.libhunt.com/l/common-lisp

Jach 6y ago

Nice write up. A small extra note for the community section, I've really appreciated Planet Lisp's (http://planet.lisp.org/ http://planet.lisp.org/) RSS feed. It aggregates a bunch of other feeds so you can more easily keep track of what's going on in the Lisp world.

vasergen 6y ago

Out of topic, but as somebody who interested in lisp generally, I have a question, from which dialect would you suggest to start? I am a little bit lost. I am considering clojure, racket and common lisp. I am reading at the moment sicp book and do exercises in `racket sicp package` which is again another dialect. After that want to start with something modern. What was you way to lisp?

tines 6y ago
To me, the entire point of Lisp, the thing that sets it apart from other languages, is unhygeinic macros. Since that is my view, I can only recommend Common Lisp. CL is the opposite of modern, but just because something is modern doesn't make it good, nor does old make bad.
- bjoli 6y ago
  As someone who has written a lot of CL and now deals mostly in scheme, why is an unhygienic macro system important? I don't think it matters much, and frankly I think something like vanilla syntax-case isn't hygienic enough. Either I don't want to care about accidentally capturing identifiers (and be very explicit when I do want it - Day like in srgi-72), or I want to have a system where I deal with explicitly (defmacro) Which I am using matters very little.
  - varjag 6y ago
    In a lisp-1 like Scheme it's a lot easier to shoot yourself in the foot with unhygienic macros.
    - bjoli 6y ago
      I don't think that matters. Either you write a macro that is correct that won't break because of unwanted intersection with the place of expansion, or your macro is wrong. Edit: barring code-walking macro of course. Once you start using those, the bets are off. Edit2: of course, I don't think overwriting core forms count either. That is poor bedside manners :)

kras143 6y ago

The best progamming book I have read so far is "On Lisp". Reading that book and coding Lisp for sometime was the best time I spent programming. Unfortunately, the whole thing was purely academic. Thanks for the effort and the information you put together.

retzkek 6y ago
Note that PG has made "On Lisp" available for free: http://www.paulgraham.com/onlisptext.html http://www.paulgraham.com/onlisptext.html
- pronoiac 6y ago
  It looks like someone else found and re-added the diagrams: http://www.lurklurk.org/onlisp/onlisp.html http://www.lurklurk.org/onlisp/onlisp.html

reikonomusha 6y ago

I think this article (of sorts) is definitely helpful for onlookers to Common Lisp, but doesn't provide the full "story" or "feel" of Common Lisp, and I want to offer to HN my own perspective. Disclaimer #1: I've been working professionally as a Common Lisp programmer---not as a contractor!---for the past decade. I have a vested interest in the language and hiring for it. Disclaimer #2: I am going to ignore commercial implementations of Lisp here, which provide very useful and advanced features, like GUI development, a user-friendly IDE, paid support, etc. [1,2] So let's get started. Common Lisp's best feature is that it allows you to be insanely productive at the "raw programmer" level. You can write, edit, and debug code very quickly and incrementally, and end up with safe & performant code. There's a price to pay: currently the best-in-class experience is still Emacs and SLIME (which come nicely packaged here [3]). As an Emacs fan, that's the best news, but to my fellow PyCharm/VSCode/vim users, it's terrible and alienating news. My colleagues who aren't Emacs users managed to learn just enough Emacs to be productive in a week, but they still frequently fired up their editor of choice in times of need. It really is worth underscoring that the Emacs+SLIME experience truly fits Common Lisp development like a glove, and the experience, in my opinion, is better than almost every mainstream editor environment out there. Common Lisp's worst feature is that it feels like just about everything imaginable has a catch. I don't mean "there's no free lunch", I mean that things just plainly don't feel cohesive or "100%" most of the time. To name a few examples: 1. GUIs: If you want to make a traditional, native GUI using open source solutions, you're stuck with really goofy libraries that are non-obvious to get working. As the article points out, you have options. Lisp actually has a renowned framework called CLIM, but I consider the open-source implementation McCLIM [4] currently only principally useful to hobbyists and hackers. 2. Deploying applications: Almost every implementation of Lisp has some way to create an executable. But very important aspects that real people care about in production are missing, inconsistent, or poorly documented. For example, almost no open source implementations of Lisp have first-class support for signing binaries on MacOS. Almost no open source implementations have a "tree shaker" to remove unnecessary cruft from the executable. Almost no open source implementations make building a shared library practical. 3. Libraries: Many libraries don't do even usual things people might want to do. The linear algebra library MAGICL [8], for example, doesn't at the time of writing have a way to solve the matrix equation Ax=B. This isn't due to laziness of the authors or lack of foresight, but rather that it's a library that's just not used by enough people to see regular, high-quality contributions as an open-source project. I'm sure MAGICL solves problems for the authors, but the authors haven't taken it upon themselves to make a general, useful, and quasi-complete library for matrix programming in Lisp. These examples are just examples, maybe not even the top examples. There are many things I wish for Common Lisp, but there are two I think I wish most. First, I wish Common Lisp implementations put in work so that they could play nice with other programming languages. Google [11] recently came out with support for protobufs in Lisp, which is nice, but I feel something deeper is needed. I think Common Lisp implementations supporting building C ABI-compatible shared libraries would be an insanely big step forward; it'd mean that Lisp could feasibly used by every language out there. Right now, the closest we've got is Embeddable Common Lisp, an implementation of Lisp which makes embedding Lisp within C relatively painless, but as usual, it has many catches [12]. The way I've coped is to produce stand-alone command-line applications, or to build servers with HTTP APIs. But it feels icky, especially if you're working with Python programmers who want to `import` stuff and not run servers just to get some code to work. Second, another thing that I constantly hope for in the Lisp world is for more "hyper productive" programmers to join it, or programmers whose livelihood depends on it. Of course, since Lisp is used by hobbyists, you see tons of hobbyist code. To be sure, a lot of this hobbyist code is perfectly fine. Usually it works, but it's just a tad incomplete. However, in my opinion, the worst thing about hobbyist code is that it usually doesn't do something useful. What does "useful" even mean? I won't claim to be able to define this term in a one-size-fits-all fashion, but "useful" to me is about getting practical computing work done. The further away from being concrete the library is, typically the less useful it is. For example, a typical Lisp programmer will have a penchant for writing a domain-specific language for parsing binary files (cool!), will open-source that code (cool!), but then nobody---including the author of said library---will actually use it to, say, write a parser for GIFs [5]. When somebody does come along to write a GIF parser, they're likely not going to use this general binary parsing framework, but hand-roll their own thing. In Lisp, it seems popular to solve meta-problems instead of problems, which is partly due to the fact that Lisp lets you think about problems at very high levels of abstraction using its advanced object system, the meta-object protocol, and macros. (One of my biggest "pet peeve" projects in Lisp, second only to "utility libraries", are documentation generator libraries. As soon as somebody figures out that documentation strings can actually be programmatically queried in Lisp, they invariably write a baroque "generator" that spits out HTML. I've never, not a single time, ever, used a documentation generator for doing real, paid work. I think one Lisp programmer I know uses it nicely is Nicolas Hafner, aka Shinmera, who uses a documentation generator simply to augment his long-form documentation writing. Staple [9] is one example library of his, where you can see some generated documentation at the bottom.) "Useful" also has to do with how a library is consumed. In the Common Lisp, a library like this [6] is typical. It's a bare page (be it on GitHub or otherwise) that provides no examples, no indication of dependencies, etc. Not all libraries are like this, but you run into it frequently enough. The Common Lisp ecosystem lacks a certain "go-getter" philosophy, needed to forge through "boring" work, that some other language ecosystems seem to have. To cherry pick one example, though I don't use it, Zig [7] comes out with interesting stuff all the time that's genuinely useful. Andrew Kelley, its main developer, is putting tons of hours into getting details around deployment right (e.g., cross-compilation). Little about Common Lisp prevents a motivated person from making equally productive-enhancing strides with the language, but I find that either (a) the interest isn't there or (b) the interest is there but the interest is for developing weird, esoteric stuff in Lisp. (My favorite example of a "productive stride" that happened in Lisp is the following. For context, people talk about all the time how difficult it would be to port a Lisp compiler to a new architecture. I myself have clamored for documentation on how to do it with SBCL. But, out of nowhere, some grad student named Charles Zhang came out with a port of SBCL to RISC-V. Not only did he port it, he's maintained it with 100s of new commits, making it more performant and less buggy [10].) Common Lisp is an amazing language purely from a practical point-of-view. As I said, to me, it's bar-none the best and most productive language to use if you want to "sit down and write code". The implementations of Lisp, like SBCL, are marvels. Lisp code, once you write it, will work forever (seriously, decades). The #lisp channel on Freenode is nice and helpful, and there are so many amazing people in the community. In Lisp, it's seamless to inspect assembly code and work with the world's most high-level, meta-object systems all at the same time. But the ecosystem mouthfeel is still off, and Common Lisp would greatly benefit from programmers obsessed with making the language more useful to themselves and others today. [1]: LispWorks: http://www.lispworks.com/ http://www.lispworks.com/ [2]: Allegro CL: https://franz.com/products/allegro-common-lisp/ https://franz.com/products/allegro-common-lisp/ [3]: Portacle: https://portacle.github.io/ https://portacle.github.io/ [4]: McCLIM: https://common-lisp.net/project/mcclim/ https://common-lisp.net/project/mcclim/ [5]: There is a GIF parser though called SKIPPY! https://www.xach.com/lisp/skippy/ https://www.xach.com/lisp/skippy/ [6]: MIDI: http://www.doc.gold.ac.uk/isms/lisp/midi/ http://www.doc.gold.ac.uk/isms/lisp/midi/ [7]: Zig: https://ziglang.org/ https://ziglang.org/ [8]: MAGICL: https://github.com/rigetti/magicl https://github.com/rigetti/magicl [9]: Staple: https://shinmera.github.io/staple/ https://shinmera.github.io/staple/ [10]: Charles Zhang's SBCL commits https://github.com/sbcl/sbcl/commits?author=karlosz https://github.com/sbcl/sbcl/commits?author=karlosz [11]: CL-PROTOBUFS: https://github.com/qitab/cl-protobufs https://github.com/qitab/cl-protobufs [12]: Poorly documented, performance isn't very good, it's maintained by essentially one person, the rituals needed to use ECL-built libraries are more extensive than necessary, build times are insanely slow, ...

pid_0 6y ago

I just don't get the appeal of Lisps. They look so ugly and the syntax seems crazy ((((((((((((((((( by the way

iainctduncan 6y ago
tastes differ. I'm a lot more averse to: end end end end or in JS: }); }); }); });
- pid_0 6y ago
  Yes both are ugly, which is why Python is so great. Go is also nice.
  - iainctduncan 6y ago
    Agreed. Though I'm mostly a scheme and C hacker these days, I did Python professionally for about 13 years, and that is a very nice side effect of the whitespace thing. On the other, Python has no decent equivalent of Lisp's let, and complex or nested Clojures of anonymous functions are butt ugly in Python, so now I'm happy with my parens.
    - deleted 6y ago
      [deleted]
kazinator 6y ago
That much stacking of opening parentheses is never seen, only ))))))). Typing )))... is easy; just hold down the ) key to repeat, and watch the cursor jump back and forth due to parenthesis-matching. When it flicks back to the correct target, release, and backspace over any overshot parens.
noidesto 6y ago
Look crazy to fresh eyes. I've found it to be a non-issue the more I write lisp code. With structural editors like parinfer, paredit, smartparens, etc. it becomes a whole lot better.

galaxyLogic 6y ago

A question: How does CLOS rate in terms of "functional purity". Or does it matter? The biggest selling point of Haskellers seems to be that Haskell is a "pure" functional language. Are there practical problems caused by mutable data in CLOS?

reikonomusha 6y ago
CLOS doesn’t require the use of mutation and in fact has explicit options to make data read-only. So it’s a matter of personal discipline whether you mutate or not, though I’d say it’s entirely idiomatic to mutate.
aidenn0 6y ago
I'm not sure I understand the question. You can write CLOS code in a pure-functional manner, or you can choose not to. Generic-functions are, in general, more useful for some types of functional programming than the typical single-dispatch style used by most other languages. Haskell and common lisp are at nearly opposite ends of the spectrum on many design decisions (Haskell is a Lazy, curried, typed language with lots of syntax and custom infix operators; Common Lisp is a (usually) eager, mostly[1] untyped language with little syntax and only prefix operators) 1: I say mostly because CL does have type declarations, but it's not defined how (or even if) the declarations are enforced in the CL standard. SBCL is arguably a typed implementation of CL, but even then, the fact that you can't in any useful manner[2] describe a type that is "A list of items of type X" in CL puts it in strong contrast to Haskell's rich type system. 2: You can use a "satisfies" type, but satisfies type declarations are ignored at compile time, so even in SBCL they are largely just syntax-sugar for assertions.
- galaxyLogic 6y ago
  I think everybody agrees that immutable data-structures are preferable to mutable ones if it is possible to get by without mutation in practice. In Haskell it seems it is difficult to mutate data, whereas in Lisp not so. If immutability is good then it would seem it is best if you can enforce immutability at the language level. I'm just wondering whether mutability is a downside of Common Lisp?

tmwed 6y ago

One thing that really bugs me about CommonLisp, is that docs for the supposedly popular libraries are often broken, because they relied on a 3rd party service QuickLisp. A great example of this, is the linked “Clack Getting Started Guide” in the article isn’t even referenced in the clack library repo. This guide than proceeds to link to the broken QuickLisp docs. It’s madness, especially for people that WANT to help move this language forward and increase adoption.

reikonomusha 6y ago
Do you mean Quickdocs? That was a passion project of someone who decided to stop maintaining it. It’s open source and can regenerate docs to be up-to-date. The author simply decided he doesn’t want to maintain it anymore due to other life/health circumstances. Quicklisp has nothing to do with documentation. That’s a distribution mechanism.
aidenn0 6y ago
I wrote the Clack getting started guide. I fixed the broken link you pointed out.

dhab 6y ago

I recently tried learning CL, and was dismayed at the tooling. While Emacs + SLIME seems to be the recommended way to go, yielding great experience; I could not realise that because I could not get SLIME to work with EMACS, and couldn't get any help in resolving it. This was after having it work on a previous macbook. Then changed the laptop, tried installing it and got stuck. Led me to give up learning it at all. I'd like to add better onboarding to the list of things to improve

heracles 6y ago
The article does mention Portacle, which is very easy to install on MacOS. I'd recommend you try it to see if there's any trouble.
vindarel 6y ago
I agree that was an issue. Now the SLIMA plugin for Atom is very good and getting very close to Slime. The ones for Sublime and VSCode are getting close too. Dandelion for Eclipse allows to get started very easily (but is less complete).
jnxx 6y ago
maybe you just need a Linux laptop, like some old Thinkpad with Ubuntu. Install time is 15 Minutes or so. Emacs is included by default.