Common Lisp
lisp-lang.org
lisp-lang.org
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.
Of course you will never please everyone, especially in the extremely heterogeneous Common Lisp community, but I think it looks sharp.
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/
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.
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.
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 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!
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.
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.
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.
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.
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.
That should be https://ocaml.org/ of course :).
Besides the examples Zababa offered, I’d say the home pages for Ruby, Julia, and Python are also good:
The current standard library is a bit limiting and there are a bunch of good ideas that it could borrow from Clojure (literals? Anyone?)
query = from u in "users",
where: u.age > 18,
select: u.nameYou can come up with something like:
(from u in users where u.age > 18 select u.name)
Lisp-2 are still alive; emacs lisp is a lisp-2. If you extrapolate hard enough, both Erlang and Elixir are lisp-2.
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.
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 ;=)