Common Lisp(lisp-lang.org)
lisp-lang.org
Common Lisp
https://lisp-lang.org/
62 comments
I built this around 2015-2016, the idea was to have a "soft" landing page with the headlining features (stability, performance etc.) and links to further pages: the success stories page[0] (which should have been emphasized more) and the wiki[1].
[0]: https://lisp-lang.org/success/
[1]: https://lisp-lang.org/wiki/
[0]: https://lisp-lang.org/success/
[1]: https://lisp-lang.org/wiki/
I thought this was a recent effort, so I'm sorry if I was too harsh.
I agree that a language homepage should be information dense, and give the new user a clear overview without having to scroll. I think the Common Lisp homepage is an improvement over what I remember from years ago, and while it’s visually appealing it’s not as immediately useful as I’d like.
Besides the examples Zababa offered, I’d say the home pages for Ruby, Julia, and Python are also good:
https://www.ruby-lang.org/en/
https://julialang.org/
https://www.python.org/
Besides the examples Zababa offered, I’d say the home pages for Ruby, Julia, and Python are also good:
https://www.ruby-lang.org/en/
https://julialang.org/
https://www.python.org/
They are all good examples too.
> A good example of what I like might be the OCaml homepage https://lisp-lang.org/
That should be https://ocaml.org/ of course :).
That should be https://ocaml.org/ of course :).
Good catch, thanks!
They mention the Cookbook on the books page: https://lisp-lang.org/books/ (btw Fernando is also the one who did the initial effort to port the Cookbook from Sourceforge to Github pages. When lisp-lang.org was released the Coobook looked bad and didn't have a lot of content).
The website seems to be done by one guy only and abandoned (look at the "news" section).
I wish LISP 2 was never abandoned. https://en.wikipedia.org/wiki/LISP_2
When reading "Lisp-2", Most lisp programmers will probably think of the lisp dialects with 2 namespaces, one for value binding, one for function binding. See
https://andersmurphy.com/2019/03/08/lisp-1-vs-lisp-2.html
Lisp-2 are still alive; emacs lisp is a lisp-2. If you extrapolate hard enough, both Erlang and Elixir are lisp-2.
Lisp-2 are still alive; emacs lisp is a lisp-2. If you extrapolate hard enough, both Erlang and Elixir are lisp-2.
Common Lisp is another example of a Lisp with 2 namespaces.
Common Lisp has more than two namespaces.
The point is that it has more than one.
The point is he wrote "two", not "more than one".
". . . with a namespace for functions that is different from the one for ordinary values", then!
I got into this trouble by wanting to avoid contributing to the perpetuation of the terms "Lisp-1" and "Lisp-2". I find those 2 terms regrettable because using a short name for a concept implies that the concept is important, but whether functions share the same namespace as values do is not IMO an important decision in the design of a programming language: changing the decision changes the character of the language in only a few superficial ways.
I got into this trouble by wanting to avoid contributing to the perpetuation of the terms "Lisp-1" and "Lisp-2". I find those 2 terms regrettable because using a short name for a concept implies that the concept is important, but whether functions share the same namespace as values do is not IMO an important decision in the design of a programming language: changing the decision changes the character of the language in only a few superficial ways.
Yeah. Lisp 1s are more common though. Racket, Scheme, Clojure, ... Hell, Javascript is also a lisp 1.
Not really. See http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt...
Chill, man. I know I was stretching. It is undeniable that javascript took inspiration from lisp/scheme.
It exists somehow with Elixir. It's not homoiconic and the interactive development experience is far from being as good as Common Lisp or even Clojure but it supports metaprogramming at an advanced level, is functional and dynamically typed.
Arguably, CGOL later did this concept better, using portable Lisp code.
Why do we see programming language webpages and Wikipedia pages submission from time to time?
Because thats what Hacker News is:
A site which people ping with interesting and noteworthy things they stumble about and then other people decide if they think it's actually noteworthy until it's either on the front page or dropped out.
Wikipedia and other web pages can be quite noteworthy.
Through sure once everyone has seen it it's no longer note worthy.
That's why some really noteworthy things pop up on HN again and again with gaps of a few month/a year between: People think they are noteworthy, push them then "everyone" knows them so they are no longer noteworthy but then people forget and wups, it's up on the front page again ;=)
A site which people ping with interesting and noteworthy things they stumble about and then other people decide if they think it's actually noteworthy until it's either on the front page or dropped out.
Wikipedia and other web pages can be quite noteworthy.
Through sure once everyone has seen it it's no longer note worthy.
That's why some really noteworthy things pop up on HN again and again with gaps of a few month/a year between: People think they are noteworthy, push them then "everyone" knows them so they are no longer noteworthy but then people forget and wups, it's up on the front page again ;=)
This looks like a rewrite of this web site? I don’t remember it looking so visually appealing.
I would hope that every programmer has a “happy language” that they most enjoy using. CL is my happy language, both for personal projects and also since around 1982 I have probably been paid to use Common Lisp for about five of the last 39 years.
This may sound sacrilegious, but in modern times I steer people newly interested in Lisp languages towards Racket. There are also many great Scheme implementations.
For my own development I use LispWorks Pro, which is pricey but extremely well supported. SBCL is probably the best open source CL system, and I often use it side by side with LispWorks.
I would hope that every programmer has a “happy language” that they most enjoy using. CL is my happy language, both for personal projects and also since around 1982 I have probably been paid to use Common Lisp for about five of the last 39 years.
This may sound sacrilegious, but in modern times I steer people newly interested in Lisp languages towards Racket. There are also many great Scheme implementations.
For my own development I use LispWorks Pro, which is pricey but extremely well supported. SBCL is probably the best open source CL system, and I often use it side by side with LispWorks.
How do you find Lisp work, out of interest? Especially for an experienced professional without commercial lisp experience?
There are some jobs. We see announces on /r/lisp, Twitter, LinkedIn… sometimes very informal ones. Some companies still pick up CL, for instance: https://github.com/azzamsa/awesome-lisp-companies/ (it's possible that Ravenpack is still hiring?). A good way is of course to learn CL and have something ready to show. Some announces don't require a (commercial) Lisp background though, they seek high-level engineers. Another way is to use CL for yourself, at current job or not. There's plenty of space for that. I use it for new services, instead of extending a Python aging monolith (DB access, FTP connection, XML parsing of a big dataset, a simple web frontend,…). I have even been doing live reloads for a year, installing new libraries while the app is running, and it's been a joy so far. I found one bug (with Sentry alerts of course), because I used = where a number could be nil. So I use `equal`. I am happy, I am productive, deployment is easy and the app is fast.
I enjoy developing in Lisp but the number of jobs are smaller than Python/C++/Java/etc.
I enjoyed, now it is time to get some books. Wished Scheme did the same.
I feel inspired to start with Lisp after being disappointed with the "open" source scene of 2021. I'd rather pay LispWorks a yearly fee and be left alone than dealing with unbalanced people in the Python space. The free Lisp implementations also look somewhat isolated from the ideological wars.
However, a C interface is required. Is this one the recommended solution? Is it really portable?
https://common-lisp.net/project/cffi/
What is the speed compared to a Python C extension? Are implementation-specific C interfaces faster (I guess they are)?
Sorry for so many questions, but these can usually only be answered by people who have actually used the interface.
However, a C interface is required. Is this one the recommended solution? Is it really portable?
https://common-lisp.net/project/cffi/
What is the speed compared to a Python C extension? Are implementation-specific C interfaces faster (I guess they are)?
Sorry for so many questions, but these can usually only be answered by people who have actually used the interface.
Comparing python's C extensions to CFFI is non-trivial because they work very differently. With Python, you implement the Python API in C, but with CFFI you implement the C API in lisp.
Re: CFFI vs. built-in API
The main difference is what features you have. For example, if you need errno, you will need to do something implementation specific (I'm currently working on a wrapper for that functionality though).
Another example: ECL let's you inline C code in the middle of a lisp program. Most other implementations don't.
As far as performance goes, the actual overhead of calling C is minimal, but if you need to copy large amounts of data, that can kill performance.
There is another library called static-vectors that let's you allocate buffers that can be used natively in both lisp and C, on the implementations that allow doing so.
Re: CFFI vs. built-in API
The main difference is what features you have. For example, if you need errno, you will need to do something implementation specific (I'm currently working on a wrapper for that functionality though).
Another example: ECL let's you inline C code in the middle of a lisp program. Most other implementations don't.
As far as performance goes, the actual overhead of calling C is minimal, but if you need to copy large amounts of data, that can kill performance.
There is another library called static-vectors that let's you allocate buffers that can be used natively in both lisp and C, on the implementations that allow doing so.
If you're interested in FFI, then yeah CFFI is the standard. The other comments addressed speed, I also wanted to point out https://github.com/rpav/cl-autowrap which is built on top of CFFI and can help get a wrapper up and running faster. After using autowrap's c-include you can then use CFFI basically like normal or some useful autowrap/plus-c's helper functions -- e.g. in one project, I have an SDL_Event (https://wiki.libsdl.org/SDL_Event) and to access event.key.keysym.scancode I have a helper function that's just (plus-c:c-ref event sdl2-ffi:sdl-event :key :keysym :scancode). Last year I wanted to try out using FMOD, and even though it's closed source and has a (to me) "interesting" API things worked easily: https://gist.github.com/Jach/dc2ec7b9402d0ec5836a935384cacdc... More work would be needed to make a nice wrapper, type things more fully, etc. but depending on the C library you might find someone's already done that (or made a start) and made it available from quicklisp.
I would give the Emacs/Slime/SBCL combo a try, it's definitely an acquired taste but pretty cool and more Lispy than anything else you will find.
The most friendly and welcoming open source communities in my experience are Ruby, Elixir and Clojure. I'm sorry you had bad experiences, but don't let that stop your projects.
"Unbalanced" python people? Do you have examples? I don't do python and have no basis of experience with python, besides the fact that I have never installed a python program successfully with their package manager.
Is python the language that has spread furthest from programming circles? It probably used to be VB mostly due to Office, but with Python at #2 in Tiobe ahead of Java and behind only C, I'd guess yes.
Is python the language that has spread furthest from programming circles? It probably used to be VB mostly due to Office, but with Python at #2 in Tiobe ahead of Java and behind only C, I'd guess yes.
Here's a good example of unbalanced people: https://github.com/pypa/pipenv/issues/2228#issuecomment-3926...
Yes, CFFI is the defacto standard, and has support for practically all implementations in use today. Nobody (but CFFI) uses the implementation-specific interfaces.
Compare SxQL to Ecto.Query, the main query DSL for Elixir:
query = from u in "users",
where: u.age > 18,
select: u.nameCommon lisp is cool but I really wish it wouldn't be an ANSI standard so the language development would continue.
The current standard library is a bit limiting and there are a bunch of good ideas that it could borrow from Clojure (literals? Anyone?)
The current standard library is a bit limiting and there are a bunch of good ideas that it could borrow from Clojure (literals? Anyone?)
I don't think being a standard is the problem. The general loss of interest in the language was the problem. If it had continued to gain or maintain interest we might've had a later revision of the standard. Other standardized languages get revised regularly, hell even Ada, Cobol, and Fortran receive updates at least once a decade.
Chialisp is interesting.
https://chialisp.com/
https://chialisp.com/
Hey, I made this! Feel free to ask anything.
I released this in 2016. It was a significant undertaking and I burned out pretty hard afterwards. I was operating under a naive "if you build it, they will come" model whereby building a modern-looking website, the community would coalesce around it and contribute to the wiki etc. But my "rallying people behind a cause" skills were insufficient.
One nice contribution: at the time Common Lisp didn't really have an official logo, which I felt was bad for marketing. So my friend made one: https://github.com/LispLang/lisplang.github.io/blob/master/a...
This was decidedly a social rather than technical effort, and social problems are hard to solve.
I released this in 2016. It was a significant undertaking and I burned out pretty hard afterwards. I was operating under a naive "if you build it, they will come" model whereby building a modern-looking website, the community would coalesce around it and contribute to the wiki etc. But my "rallying people behind a cause" skills were insufficient.
One nice contribution: at the time Common Lisp didn't really have an official logo, which I felt was bad for marketing. So my friend made one: https://github.com/LispLang/lisplang.github.io/blob/master/a...
This was decidedly a social rather than technical effort, and social problems are hard to solve.
It's really neat that you did this :)
Of course you will never please everyone, especially in the extremely heterogeneous Common Lisp community, but I think it looks sharp.
Of course you will never please everyone, especially in the extremely heterogeneous Common Lisp community, but I think it looks sharp.
Thank you! I built it to try to increase the profile of Common Lisp and have a gentle on-ramp to get new users into the community.
The website looks good! Do you still use Common Lisp? If not, what are the reasons?
I like Common Lisp but I no longer use it. I'm pretty much completely burned out on dynamic typing. It feels like building on sand. I want calmer programming, even if it's less powerful. At present I'm building a new language[0] with that goal in mind.
[0]: https://github.com/austral/austral
[0]: https://github.com/austral/austral
I also want static type-checking in my programs. However, reluctant to give up CL, I've been using type annotations, which SBCL will check at compile-time. Is there a particular reason you're not doing this?
I'm curious how extensively you use automated tests in dynamically-typed languages? I find that the types in statically-typed languages, especially OCaml, take up a lot of the load of tests.
Of course, types can prove things tests can't, and especially the linear types you're using in Austral.
I've been wondering what a "tiny Rust" would look like, so Austral looks pretty interesting.
Of course, types can prove things tests can't, and especially the linear types you're using in Austral.
I've been wondering what a "tiny Rust" would look like, so Austral looks pretty interesting.
Check out https://coalton-lang.github.io/ !
That one is quite interesting indeed.
And they use it for quantum computing research:
"One of the state-of-the-art optimizing quantum compilers is an open-source program called QUILC with a companion quantum computer simulator called the Quantum Virtual Machine. Both of these programs are written in 100% Common Lisp, and contain a total of around 50,000 lines of sophisticated, mathematical, data structure–heavy code. And that excludes the plethora of first-party dependencies.
Common Lisp is a fantastic language for developing these programs; it’s fast, stable, extremely flexible, and the developer experience is unmatched. But, both new and seasoned developers sometimes get tripped up and tangled in the web of complex data structures, and inadvertently introduce type errors that the relatively comprehensive test suite doesn’t catch. In addition, such developers heavily rely on documentation strings (“docstrings”) in order to discover what the probable inputs and outputs of the functions are, and those docstrings sometimes go stale.
Coalton’s aim is to allow us to reap the benefits of Common Lisp, and not have to rewrite 50,000 lines of tricky code in order to realize some of the benefits offered by statically typed functional programming languages." https://coalton-lang.github.io/20211010-introducing-coalton/
And they use it for quantum computing research:
"One of the state-of-the-art optimizing quantum compilers is an open-source program called QUILC with a companion quantum computer simulator called the Quantum Virtual Machine. Both of these programs are written in 100% Common Lisp, and contain a total of around 50,000 lines of sophisticated, mathematical, data structure–heavy code. And that excludes the plethora of first-party dependencies.
Common Lisp is a fantastic language for developing these programs; it’s fast, stable, extremely flexible, and the developer experience is unmatched. But, both new and seasoned developers sometimes get tripped up and tangled in the web of complex data structures, and inadvertently introduce type errors that the relatively comprehensive test suite doesn’t catch. In addition, such developers heavily rely on documentation strings (“docstrings”) in order to discover what the probable inputs and outputs of the functions are, and those docstrings sometimes go stale.
Coalton’s aim is to allow us to reap the benefits of Common Lisp, and not have to rewrite 50,000 lines of tricky code in order to realize some of the benefits offered by statically typed functional programming languages." https://coalton-lang.github.io/20211010-introducing-coalton/
Can you elaborate on linear types? What do they bring to the table and how do they work ?
Hi! When will you come back and write new useful libraries? Best,
This website (and all the author's libraries) was such a refresher. It has been important for me to not run away from CL (again). At that time, the "official" website, the first Google result for CL looked like this: https://web.archive.org/web/20160305135106/https://common-li... Fortunately, they revamped it circa 2018: https://common-lisp.net/ (work mainly due to @mmontone if I'm not mistaken). Since then, the Cookbook was expanded with useful content (it was kind of hard to find up to date information online, on even simple matters like how to build a binary) and we got some useful lists too, like https://github.com/CodyReichert/awesome-cl and a list of (current, existing) companies: https://github.com/azzamsa/awesome-lisp-companies/ Hopefully it's easier than ever to have your questions answered and start hacking in Lisp!
Another very helpful resource by Fernando was his state of CL ecosystem: https://borretti.me/article/common-lisp-sotu-2015 It really helped have an overview of the ecosystem, pick libraries and work on consolidation. I compiled one for 2020 here: https://lisp-journey.gitlab.io/blog/state-of-the-common-lisp...
(ps: yes people, you can avoid Emacs and use VSCode to have a good experience! and even Atom, Jupyter notebooks and more. See https://lispcookbook.github.io/cl-cookbook/editor-support.ht...)
Another very helpful resource by Fernando was his state of CL ecosystem: https://borretti.me/article/common-lisp-sotu-2015 It really helped have an overview of the ecosystem, pick libraries and work on consolidation. I compiled one for 2020 here: https://lisp-journey.gitlab.io/blog/state-of-the-common-lisp...
(ps: yes people, you can avoid Emacs and use VSCode to have a good experience! and even Atom, Jupyter notebooks and more. See https://lispcookbook.github.io/cl-cookbook/editor-support.ht...)
I've been curious about Common Lisp in the past but never really got started because I can't seem to find very good documentation. What do veteran CL users use as a reference? This maybe? http://www.lispworks.com/documentation/HyperSpec/Front/index...
I suppose I've "become accustomed to a certain lifestyle" coming from Racket's excellent documentation. But even if you ignore Racket, the R6RS reference (for example) seems way more readable than the CL spec: https://docs.racket-lang.org/r6rs/r6rs-std/index.html Same goes for Clojure, which I've never used: https://clojure.org/reference/documentation
This is not meant to be an attack on Common Lisp; I'm just trying to learn.
EDIT: I just saw https://lisp-lang.org/spec/ which says "We're currently working on parsing the TeX sources of the specification to generate a more modern version of the CLHS. This might take a while." I'm looking forward to seeing the result!
I suppose I've "become accustomed to a certain lifestyle" coming from Racket's excellent documentation. But even if you ignore Racket, the R6RS reference (for example) seems way more readable than the CL spec: https://docs.racket-lang.org/r6rs/r6rs-std/index.html Same goes for Clojure, which I've never used: https://clojure.org/reference/documentation
This is not meant to be an attack on Common Lisp; I'm just trying to learn.
EDIT: I just saw https://lisp-lang.org/spec/ which says "We're currently working on parsing the TeX sources of the specification to generate a more modern version of the CLHS. This might take a while." I'm looking forward to seeing the result!
My favorite quick reference I have printed out is http://clqr.boundp.org/ It's nice to just quickly explore what's available in the base language too.
But when I don't want to flip through it, or find the short description for something insufficient, then yeah the HyperSpec is usually my first stop for quickly referencing something. I use vim, so I just move my cursor over a symbol and type ",h" and that opens a browser tab on that thing in the hyperspec -- e.g. if I want to remind myself what the state parameter of make-random-state does, I open http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_r... Though I often first type ",s" which is just an alias for (describe 'symbol) which shows me locally the symbol documentation, and for this one I'd learn the same thing without having to have my browser open. I think some people configure their emacs to do the common IDE thing of showing you the doc along with the function signature as you type, I just have the latter. I also make use of jump-to-source since reading the code is often the quickest way of answering a question about it.
PAIP is a great book, but I tend to use PCL as a quick reference: https://gigamonkeys.com/book/ Especially until you use classes/format/conditions/loop enough to get used to them, chapters 17/18/19/22 are helpful. It's still a recommended first book for newcomers that's worth going through entirely though, not just as a reference.
https://lispcookbook.github.io/cl-cookbook/ is a useful community cookbook with info on a lot of topics.
CLTL2 is a reference I haven't used that much, there are a few things that are in it that didn't make it to the ANSI spec, but what I have read I've found useful and clarifying. https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node1.html Guy Steele (whose 67th birthday is today) is a great writer.
But when I don't want to flip through it, or find the short description for something insufficient, then yeah the HyperSpec is usually my first stop for quickly referencing something. I use vim, so I just move my cursor over a symbol and type ",h" and that opens a browser tab on that thing in the hyperspec -- e.g. if I want to remind myself what the state parameter of make-random-state does, I open http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_r... Though I often first type ",s" which is just an alias for (describe 'symbol) which shows me locally the symbol documentation, and for this one I'd learn the same thing without having to have my browser open. I think some people configure their emacs to do the common IDE thing of showing you the doc along with the function signature as you type, I just have the latter. I also make use of jump-to-source since reading the code is often the quickest way of answering a question about it.
PAIP is a great book, but I tend to use PCL as a quick reference: https://gigamonkeys.com/book/ Especially until you use classes/format/conditions/loop enough to get used to them, chapters 17/18/19/22 are helpful. It's still a recommended first book for newcomers that's worth going through entirely though, not just as a reference.
https://lispcookbook.github.io/cl-cookbook/ is a useful community cookbook with info on a lot of topics.
CLTL2 is a reference I haven't used that much, there are a few things that are in it that didn't make it to the ANSI spec, but what I have read I've found useful and clarifying. https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node1.html Guy Steele (whose 67th birthday is today) is a great writer.
Norvig's PAIP is what won me over from Scheme to Common Lisp. https://github.com/norvig/paip-lisp
That might just be a consequence of my time on Hacker News, but I think the insistance on Paul Graham is a bit much.
The chart about server performance felt a bit weird to me, as I think the difference between Ruby and JS would be bigger at least. So I checked on techempower benchmarks (https://www.techempower.com/benchmarks/) and sadly there is no common lisp. It's also not on the last runs (https://tfb-status.techempower.com/). I think putting the origin of the results and a way to reproduce them would be a good thing. I don't doubt that common lisp is fast, but that diagram looks a bit too much like hollow marketing, especially with the image behind.
The page about OO (https://lisp-lang.org/learn/clos) has a good explanation of multiple dispatch, but I think it should come with an example. The first steps pages (https://lisp-lang.org/learn/first-steps) also explains atoms well, but it doesn't explain lists after mentionning them.
In general this feels a bit unpolished, though some part are good. There's no mention of the Common Lisp cookbook (https://lispcookbook.github.io/cl-cookbook/), which sadly confirms a bit the "Lisp users all have NIH syndrome" meme.