I started a big project at work using Common Lisp in 2017 and could not be happier. Sure, most nice features have trickled down to other languages, but they are rarely as nicely integrated. And Lisp still has many advantages that are not found elsewhere: Unmatched stability, on-demand performance, tunable compiler, CLOS, condition system, and Macros to name a few. It has its warts too but which language does not?<p>I found lack of high quality library documentation a bit annoying, but a non-issue, there were tests and/or examples included in practically all of the libraries I have used so far.<p>Lastly, this rarely gets brought up, but I think Common Lisp has some of the best books available out of any programming language. The fact that it is so stable means that most of material, and code, from the end of 80's and 90's is quite relevant today, and new stuff is being written.<p>The biggest downside is that it makes JavaScript and Python revolting to work with. But I can still enjoy SML for example.
I'd replace the first few steps with "Install Roswell" -<p><a href="https://github.com/roswell/roswell" rel="nofollow">https://github.com/roswell/roswell</a><p>Roswell will install a Lisp and QuickLisp for you, and give you a single point of entry to install libraries, create and run code, and launch en editor (Emacs with Slime of course).<p>I can't recommend it highly enough (I'm nothing to do with the project, just a very happy user).
I'm used to languages like Python, that have a number of files that are modules, and to start a program you run one of them as an entry point.<p>C programs consist of a lot of files that are compiled and linked into a binary executable.<p>Whenever I've tried to learn CL, I couldn't really wrap my head around what the eventual program would be. You build an in-memory state by adding things to it, later dump it to a binary. How do you get an overview of what there is?<p>I'm just too used to my files, perhaps. Or I'm missing something.
I've been working on a CL project for a couple of years. Was my first big stab at using CL for something other than a toy.
Sbcl is a nice choice, but far from the only option. It has many tradeoffs.
CL is not without its frustrations. Documentation that has not aged well. A community that can be less than welcoming.
(in contrast to say the Racket community)
Inconsistencies, e.g. first, nth, elt, getf, aref...
However portability appears to be a strong point vs on the scheme scene.
Single binary compilation on SBCL/LW/ACL/CCL are great. Found GC to sbcl to be lacking on large garbage rates. Tended to promote garbage to a tenure that prevented it from being removed. It would max out 32GB of memory, even with explicit gc's enabled between files. Where as the other implementations would stay below 4GB.<p>So ymmv.<p>Performance benchmarks using cl-bench really highlighted some strong points <a href="http://zeniv.linux.org.uk/~ober/clb" rel="nofollow">http://zeniv.linux.org.uk/~ober/clb</a>
AWS Cloudtrail parser. <a href="https://github.com/kunabi/kunabi" rel="nofollow">https://github.com/kunabi/kunabi</a>
Hi, HN! I made this! Ask me any questions you like. I'll try to respond as the workday progresses and I wait for deploys to complete!<p>paul@nathan.house if you want to email me instead. (or @p_nathan on Twitter, if that's your thing).
Some notes based on my (brief) experience toying with Common Lisp:<p>* Why hasn't anyone made a more eye-frendly version of the Common Lisp Hyper Spec ? Having good, easily-browsable documentation is a core-problem.<p>* The relation between the various native data-types were quite unclear to me.<p>* dealing with the external world was quite a mess. Many project/libraries implementing only half of something and then got abandoned.<p>* some libraries had a compatibility matrix... with common lisp implementations. that seemed weird to me.
If you're so inclined I'd make it a "living document" that gets updated as the state-of-the-art evolves. Writing CL in 2017 is not likely to change rapidly in the next decade but even compared to what writing CL was like 8 years ago it has changed enough.<p>Nice job.
While I remember - we need a refreshed SOTU for 2017. 2015 one[0] seems to be still mostly correct, but the CL scene is pretty active.<p>[0] - <a href="http://eudoxia.me/article/common-lisp-sotu-2015" rel="nofollow">http://eudoxia.me/article/common-lisp-sotu-2015</a>
For people using macs, it's probably worthwhile to mention CCL's IDE, which you can easily build from within the CCL sources using (require :cocoa-application), or which you can get for free from the Mac App Store (it's called "Clozure CL").<p>It's a little bit bare bones and a little bit perpetually unfinished, but it works and it gives you a Lisp-aware environment for editingand running Lisp code, and even has a few handy tools.
>Repository for local libraries with the ASD files symlinked in<p>This method is so old, I can't believe people are still doing this. You can easily setup ASDF to look in a subtree of a directory and never care about it finding your libraries again.<p>[1] <a href="https://common-lisp.net/project/asdf/asdf.html#Configuring-ASDF-to-find-your-systems" rel="nofollow">https://common-lisp.net/project/asdf/asdf.html#Configuring-A...</a>
How does Common Lisp compares to Racket nowadays? I've seen a lot of activity but I can't decide which one to try out. I only have time for one of them ATM.
If you have a Mac you should try Clozure Common Lisp (<a href="http://ccl.clozure.com" rel="nofollow">http://ccl.clozure.com</a>). It has an integrated IDE so you don't have to futz with emacs and slime.<p>Also, this library smooths over some of CL's rough edges:<p><a href="https://github.com/rongarret/ergolib" rel="nofollow">https://github.com/rongarret/ergolib</a>
Ah yes this is exactly what I needed. I was recently trying to start a CL project but I had trouble wading through all the outdated material, especially with regards to including external packages. Thanks for putting this together!
Wondering if anyone has any experience using lisp for machine learning? I'm aware of mgl[0], but it seems to be abandoned. The lack any wrappers for tensor flow or caffe is also a bit surprising to me. The cliki page [1] is also unhelpful and out of date. Is machine learning on lisp dead or are there projects out there that I'm just not aware of?<p>[0] <a href="https://github.com/melisgl/mgl" rel="nofollow">https://github.com/melisgl/mgl</a><p>[1] <a href="http://www.cliki.net/machine%20learning" rel="nofollow">http://www.cliki.net/machine%20learning</a>
I wrote in Common Lisp the star map generation software at the core of my startup, <a href="http://greaterskies.com" rel="nofollow">http://greaterskies.com</a>, and could not be happier. But now that it's getting off the ground I wonder whether it may adversely impact my chances of being acquired. Are there any known examples of recent CL-based startups?
If emacs is an obstacle to Common Lisp in 2017, maybe what's needed is a Lisp-interaction plugin for vi(m) (or whatever it is that vim uses in lieu of emacs modes). I don't get the hype for modal editing but you can't argue with the data clearly showing emacs users are in the minority.
If somebody is not comfortable to use emacs (I am), there is a atom plugin for use with CL: <a href="https://atom.io/packages/atom-slime" rel="nofollow">https://atom.io/packages/atom-slime</a><p>It doesn't replace emacs, but it works as a first Lisp ide.
While people are directing their attention here:<p>Last year I looked into Common Lisp for a while, but got turned off when I found that there's no distinction between the empty list and boolean false (or nil, in CL-speak).<p>I found this kinda weird and vaguely off-putting. I don't want to write code to handle the diffence between, say, an empty array and false or null in deserialized JSON data.<p>Can anyone comment on whether this comes up as an actual issue in practice?
"Dear windows user, tell us how this is done for SBCL"<p>Watch YouTube video from Baggers. It's a lot more complicated than your average windows user will want to go through. Than you have to setup EMACS, quicklisp...etc. I never really new what quicklisp was doing and it made me nervous (I trust VS nuget).
The biggest problem with lisp adoption imo is that the first step of every path begins with emacs.<p>Emacs needs to die for lisp to flourish in a more modern editor.<p>Light Table was a good start, but we need some power behind similar projects.<p>I always thought guilemacs was the obvious successor, but it still hasn't happened.
i do not know how to message the guy "Scott" author of page, so i am putting this here.<p>in the "LispWorks CL" page, under "Implementations", the "Notes" section elicidates a mystery about the Personal Edition not recognizing the lisp init files. This is actually a limitation in LispWorks Personal Edition which is described on the link provided to retrieve said edition.
I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang. Golang now has <a href="https://github.com/glycerine/zygomys" rel="nofollow">https://github.com/glycerine/zygomys</a> for scripting. For that matter, why would one choose Common Lisp over GNU guile ? (guile now supports fibers). What does Common Lisp offer for the working programmer that is an advantage over other languages ?