This is the document [0] we maintain for new Lisp hackers at Rigetti, where we use Common Lisp to build open source quantum software development tools. Following that, here’s the rundown of some basic Lisp nomenclature and how to edit in Emacs [1].
The article isn’t bad, but it also doesn’t provide you with a sustainable way to develop Lisp; interactive and incremental development together form a great proportion of value of using the language in the first place.
I would love to see a section about debugging, something like the series at https://malisper.me/category/debugging-common-lisp/ but I suspect it would be difficult to made it general enough (the guide above targets SBCL, Emacs and Slime)...
P.S. I should mention that I live in Emacs, but I know there are people that wouldn't touch it with a ten foot pole
- Code won’t be broken in 20 years (which I value when developing things like compilers). There’s one standard, and several de facto standard extensions.
- Almost 30 years of history, documentation, discussions, etc. Every corner of the language has been discussed to death.
- Several stable, mature, and independent choices of open source implementation.
- Implementations are written in Lisp all the way down. You can immediately jump to the definition of anything at any depth, and often edit or redefine to taste. (Example, I improved SBCL’s integer square root in my live image, and submitted a patch.) The only off-limits bits are a part of the runtime, like the garbage collector.
- Several independent choices of commercial implementation and commercial support.
- Generally easy to optimize and micro-optimize code. Easy to edit/disassemble/debug.
- Easy to write assembly code with SBCL.
- Fast start-up time, easy to compile into native executables. No JIT lags.
- Excellent IDE support through Emacs and SLIME. Incremental development is real with Lisp, and absolutely not so with Julia.
- Easy to dynamically generate and compile code at runtime.
- Poor support for numerical libraries and poor support for plotting, much to the chagrin of a scientific programmer like myself.
- No hip website or hip foundation backing it.
- Quiet community, with very broad interests. Not everybody is rallying around one theme in Lisp. You got database programmers, game programmers, scientific programmers, etc. This could be a positive, if the community were larger.
- Implementations are written in Lisp all the way down. You can immediately jump to the definition of anything at any depth, and often edit or redefine to taste. (Example, I improved SBCL’s integer square root in my live image, and submitted a patch.) The only off-limits bits are a part of the runtime, like the garbage collector.
I'd add even the GC is accessible if you have the knowledge. Grammarly has a blog post that talks in part about manipulating parts of the GC to achieve higher through put by keeping heap objects (I think!) from reclamation.
Yes, lots of tunable aspects of the GC are available at runtime. You can enable/disable GC, pin memory, control how much of the heap is dedicated to which generations, control GC rate, etc. You just can’t muddle with the actual GC algorithm readily from your image. (Not that you’d ever want to??)
One big one is that Lisp is probably much faster. Common Lisp is AOT compiled to the metal so it starts up fast and runs fast. CL is often within a factor of 2 of C speed and dramatically faster than plain Python. I haven't used Julia but recent stories on HN suggest it's no speed demon.
Lisp compilers also tend to be quite fast, compared to LLVM-based compilers (well, except for Clasp, which is a Lisp based on LLVM, but that project is aiming for tight integration with LLVM-based code compiled from other languages.)
On my desktop, SBCL will compile itself from source and run the small version of its test suite in 90 seconds.
I don't know which recent stories you're talking about. I have read only one story here recently, and it was about an outdated version of Julia.
Compare these two:
Julia should be faster than CL for long running numerical computation at least (reaching C/Fortran speed for type-stable code) as it was designed for that purpose (plus the good GPU support and use of libraries like BLAS). But there is no AoT option yet so you'll have to deal with JIT, making it much slower for any shorter running scripts because of all the compilation, which makes CL speed much more consistent across tasks.
Do you have any citation for this claim? The results from the programming language benchmark game[1] suggest that Julia is sometimes a bit faster than SBCL, one of the fastest lisp implementations, and sometimes a bit slower.
These benchmarks may not apply for every use case, but at least they suggest that Julia is roughly as fast as compiled Lisp.
From my perspective, Lisp falls into the third tier of programming language speed.
First tier (speed wise) of commonly used or discussed programming languages on HN are C++, C, and Rust. These have the performance for almost any task but require significant development effort.
Second tier languages trade off a bit of speed for other conveniences. These include Ada, C# and Java. Definitely slower than first tier, but easier to use in their own domains of use.
The third speed tier languages are many of my favorites, for example Swift, Go, Lisp, Racket, Julia, OCaml, Haskell, Javascript, and Dart. These are still fast enough for most situations and can be very productive.
I do a lot of programming in Python3 because it is just so expressive; speed wise, it occupies the forth tier with Ruby and Lua. The relative slowness isn’t a problem for many tasks and Python is really fun to program in.
Speed isn’t everything. While in grad school, for fun, I wrote a program to generate programming language parsers. Unfortunately, this was in 1974 using punched cards and the only language that I had access to was FORTRAN IV or assembly language—both very fast languages. I never got the program to a useful level of functionality (my goal was a LALR parser generator). If I had Python, it would have been a different story.
There are multiple benchmarks, but it's hard to trust anything because of varying level of skill with each language (and also there is no point in creating unmaintainable code just for speed as you say, the ideal comparison would be with idiomatic performance aware code). Also Julia is probably on tier 3, but in math problems it targets tier 1 (similarly how to python drops down to tier 1 for ML but on a language level).
https://news.ycombinator.com/item?id=19750507 (picked the discussion because combining the optimizations of two people CL got to Julia level, though Julia code is correctly written but not particularly optimized)
“It was designed for that” doesn’t justify a claim. Common Lisp is a general purpose language with excellent support for fast numerical code. In SBCL in particular you can even write assembly if you want to do crazy AVX stuff.
While it doesn't justify by itself, it means that this area will be constantly profiled and optimized tricks will be implemented to handle it better, like auto-simd, using multiple dispatch to detect optimal BLAS method for every matrix operation, implementing broadcast/loop fusion. Even matlab which will poorly handle almost anything is pretty competitive in numerical processing.
And saying CL is fast because you can write in assembly is like saying Python is fast because you can write in C. And while you can't write in assembly in Julia, you can go down all the way down to the LLVM (and intercept the compiler right between detecting types and compiling so you can rewrite every intrinsic with your new backend in a more flexible way than multiple dispatch) like they did with XLA.jl for TPUs and CUDANative for GPUs.
I'm not a fan of Roswell or Portacle, personally, because I'm used to taking control of my setup. I try to stick with well-maintained distribution systems (e.g. Debian's .deb or the source itself if need be) otherwise upgrades tend to be complex, not well documented, and supported by few people. Additionally, as one new to Common Lisp, it is difficult to understand the abstraction layer at which Roswell & Portacle operate with respect to abstraction layers implicit to Common Lisp.
I better understood these layers by installing SBCL myself and playing with Quicklisp (a package manager) and ASDF (a package definition library). I wrote about this a year ago [0]. It was confusing at first. But it became clearer after exploring and writing that post. Ultimately I don't find it very different than writing a Python library with setuptools.
re: SLIME; I never ended up remembering the keyboard shortcuts as a CL hobbyist so I turned it off after a few uses and stuck with vanilla Lisp-mode. Parenthesis completion and auto-ident are the only two tools I expect of my text editor (vs. in a GUI, buttons take the place of keyboard shortcuts you must remember). I use Emacs at work and home but I hardly remember any extension shortcuts (as much as I want to benefit from projectile and magit). It even took me a few years before I felt comfortable using package-install vs. just `git clone`-ing new modes and adding their paths to my .emacs.
For all these reasons, Portacle as a distribution isn't really my style. Roswell didn't solve anything for me either once I got familiar with ASDF and Quicklisp.
Complacency on tool UX doesn't help a community. Roswell & Portacle may be a forward iteration on UX. But I also want to share the fundamentals (or at least N-1 layer down) and get other hobbyists comfortable there too.
Adding my own disagreement about using either portacle or roswell. If you're running literally any widely used Linux distro, or {Free|Open}bsd you are a package install away from a working common lisp install. I've seen this come up alot in irc and reddit, this push to get people to use a C library (!) to get to common lisp, and its downright bizarre. If you're that bent on packaging and C, use Guile or Gambit. And if you're just a random person perusing this thread, just go download the simplest thing and get started, not slime (which is awesome) not Lem (which is fine), just lisp and a text editor
Yes. A detail that I found quite amusing about Roswell was that it segfaults on OpenBSD; the problem could have been altogether avoided by writing it in Lisp. I had to dismiss Lem because it seemed to depend on Roswell and Roswell was not going to cooperate.
The entire point of Common Lisp is to make stuff work across implementations. You shouldn’t need to test five implementations on your development machine. The only time I can see something like Roswell (but not in its current form) being useful is an automated CI tool, but even then it isn’t really necessary.
So, due to someone taking the time on irc, I managed to get Lem installed on a box at some point recently sans roswell. It doesn't actually depend directly on it, though I think there are some things built on Lem that use roswell.
Yeah, people have and had problems with common-lisp-controller, I certainly have. That being said I'm not one to turn to the arms of C to solve an environmental problem, not when it can be done correctly, if with effort, from the host language itself
I would recommend to ignore Roswell and just install SBCL or CCL from your package manager. For a quick Emacs setup with good defaults, use Spacemacs with the common-lisp layer.
If you have never used Emacs I would just ask the LispWorks guys for an evaluation license. It's the closest thing to experiencing one of those Lisp environments of the 80s (Emacs doesn't come close). You'll be impressed.
> ask the LispWorks guys for an evaluation license. It's the closest thing to experiencing one of those Lisp environments of the 80s (Emacs doesn't come close).
Could you say something about what additional features LispWorks has that Emacs doesn't?
I agree. Also, even though I usually favor using Emacs, VSCode with the common-lisp plugin is easy to install for beginners, so newbies should probably start there.
This article would have someone believe Common Lisp is any other UNIX language, where near-meaningless UNIX configuration and other things abound. It indents the Lisp in an odd fashion, with closing parentheses on their own lines, and it doesn't mention the REPL but in one paragraph.
As for Steve Losh's article, I don't recommend that one either; it recommends using a Discord server; it recommends using C libraries; it discusses performance and representation characteristics that are allowed, but not required, in interfacing with things such as graphics cards; and it has other characteristics that I don't believe someone new to Common Lisp would recognize it, so I don't recommend that article to novice Common Lispers.
Agreed. Install SBCL, Quicklisp, Emacs, and bring up Practical Common Lisp in a browser, then start hacking. Roswell doesn't add any real value, in my opinion.
I was very fortunate that my university had a ton of old Lisp books, and after browsing through a bunch of them I found some really good ones and learned from those. Unfortunately, I don't remember the titles (though a book on CLOS stands out in my memory as being an excellent introduction to the awesome power of OO programming in Lisp), but if you have a university with a good comp sci library you may want to check it out.
Parenthetically, I don't know if it's true but I'd heard that there have been more books published on Lisp than all books on other programming languages combined.
I'd also recommend that anyone who starts out with Common Lisp give a modern Scheme (like Chicken, Racket, or Guile) a try. I found Scheme to be much more to my taste and once I learned it I viewed CL as quite backwards in many ways, so Scheme is what I use today if I can at all help it.
Finally, newbies should check out Emacs and eLisp. eLisp is more primitive than either CL or Scheme, but it's still great when combined with Emacs, which you can customize and improve to your heart's content. In addition, there's a mountain of eLisp code to build on for you Emacs improvement projects. I came to eLisp after learning both CL and Scheme, so it was pretty easy to pick up, and that's what I'd recommend others do too, just so you first learn what Lisp is truly capable of.
CL has warts, but at least ANSI CL is portable across a dozen implementations, has an excellent IDE and debugger, and lots of other boring “practical” things. Scheme is fantastic, if you’re willing to write code that only works for one implementation.
I love that both are feasible options. I’m still not sure which side of the Lisp-1 vs. Lisp-2 debate I’m on, but the fact that there are such great languages on both sides of the fence is wonderful. Also, Scheme communities are more focused; this property proved extremely important to me when I was writing a CHICKEN Scheme web app.
I believe it stems from an early idea that not specifying it might allow for the compiler to do some optimisations (same reason it is not specified in C). I think it also allows for some freedom in the internal representation for continuation rewriting, and that it now would mean some problems for implementations if a certain way was specified. (Please correct me if I'm wrong about that).
It only really matters if you are passing arguments to a function that both read and mutate the same variable. In idiomatic scheme that really only happens with IO or something like srfi-121 styled generators.
> Order of evaluation of the operands of any C operator, including the order of evaluation of function arguments in a function-call expression, and the order of evaluation of the subexpressions within any expression is unspecified (except where noted below). The compiler will evaluate them in any order, and may choose another order when the same expression is evaluated again.
Every undefined behavior in a language standard is a failure of the standard making process, and should be a source of shame. Sometimes it's politically unavoidable (because there are multiple implementations that do something different), or practically unavoidable (the best behavior is not yet known, or impossible to make precise) but every such imprecision is a landmine through which bugs, often insidious ones, can enter programs.
I’m not a fan of Roswell it’s self but I see the value. The LISP ecosystem is not bash centric as most languages today are.
It wraps everything it’s own cli which, while powerful break the common interface that most developers today have become accustomed to.
I know that I would have enjoyed a good bash cli interface for managing my lisp packages using some of the notions developed in ruby / python / javascript e.g. project local installs (quick-lisp i stalls packages globally by default), project lock files for versioning, package binaries / commands (things like Rake, Rspec, NPM run scripts).
You can do all of this stuff with your lisp install it’s just more complicated and requires more steps.
Each time I see a LISP related article on Hacker News, I always ask myself why LISP is so popular only on HN. This is the only website where I hear about LISP. Is LISP popular on HN because it brings advantages to the table or is it popular because it looks cool to say you use it, or something else?
Please help me understand. I am tempted to learn it but needs justification.
HN creator Paul Graham was really into Lisp. HN has been built with his own Lisp, Arc. HN attracted many experienced programmers and experienced programmers usually like Lisp, because Lisp dialects are simple, elegant and powerful.
I understand the PG part but I don't agree with the experienced Programmers part. I know hundreds of experienced Programmers and zero of them are using LISP. I am one of them. They are using C, C++, C#, Java, JavaScript, PHP, Perl, Python etc. Anything but LISP.
I won't even be surprised if LISP has a market share of less than 0.01%. Even in the US. Do you have examples of popular system built using LISP?
I don’t think the parent meant that experienced programmers are heavy users of Lisp, or that they use it as their main language, but rather they often know it and have an interest in it, even if it’s not paying their bills.
Out of those 100s of Developers that I know, none is interested in learning LISP. Not even as a hobby. Experienced Developers have already chosen their tools and they focus on improving on those skills.
I’m interested in why you asked 100s of developers if they’re interested in Lisp.
In my experience, which is evidently quite different to yours, excellent developers also want to increase their breadth, understand which tools are good for which jobs, and generally increase their knowledge about programming and software engineering. It’s usually the poorer engineers, experienced or not, that stick to just a few tools with no knowledge of others.
They talk about what they are interested in on a daily basis. You don't even need to ask them. They will tell you.
There are millions of development tools in this world. No-one has time to learn all the tools. Even if they want to. I don't understand why LISP have to be the only exception when coming to tools a Developer can ignore. I doubt Linus Torvalds has time to learn every obscure technology out there. He focuses on delivering kick-ass solutions using C. Same as other great Programmers. It is the book writers and consultants who are busy learning each and every tool.
A bunch of programming language developers learned Lisp and were influenced by it: James Gosling (Java), Yukihiro Matsumoto (Ruby), Brendan Eich (JavaScript), Alan Kay (Smalltalk), Robin Milner (ML), ...
Hardly 'book writers and consultants'. These are among the most influential people for programmers... if you had learned Lisp decades ago, you would have learned much of the basics for those newer languages: managed runtimes, evaluation, automatic memory management, programming with first class functions, virtual byte code machines, etc etc...
Then we should relegate LISP to an academic programming language and stop pretending that it is a major player when all the data proves the contrary. LISP failed for half a century because it isn't the best tool for the job, not because we are just stupid and only the select few have the brains for it. It is not the case. It is just not good for the job at hand -> delivering solutions.
I have used 80% of those programming languages you listed in a professional environment and I didn't require to learn LISP. I didn't see any resemblence of LISP on any of them. To correct you, Java was heavily influenced by C/C++, not LISP. In such a way that my transition fron C++ to Java only took me few hours.
"Lisp isn’t a language, it’s a building material." - Alan Kay
> Then we should relegate LISP to an academic programming language and stop pretending that it is a major player when all the data proves the contrary. LISP failed for half a century because it isn't the best tool for the job, not because we are just stupid and only the select few have the brains for it. It is not the case. It is just not good for the job at hand -> delivering solutions.
Nobody claims that it is a major player. My claim was that it was influential - not academic, but actually practically. People like Matz (Ruby) literally learned how to implement a programming language runtime by studying Lisp, in this case the Emacs Lisp runtime.
> I have used 80% of those programming languages you listed in a professional environment and I didn't require to learn LISP.
Nobody said it's required. It's just that when you knew Lisp, you would have already known about garbage collection, first class functions, virtual byte code machines, managed memory, etc. Nothing which is directly in C++.
> I have used 80% of those programming languages you listed in a professional environment and I didn't require to learn LISP. I didn't see any resemblence of LISP on any of them. To correct you, Java was heavily influenced by C/C++, not LISP. In such a way that my transition fron C++ to Java only took me few hours.
If you don't know Lisp, how would you know which influence it had on Java? C/C++ had directly no Garbage Collection, no managed memory, no runtime code loading (-> Java class loader), ... thus these things about the Java runtime were not coming from C/C++. You got the curly braces from C/C++.
Guy Steele, who co-wrote the Java language spec: 'We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.'
Curly braces, for loops, while loops, if statements, case statements, variable declaration and initialisation etc. All those things were carbon copied from C/C++, not Lisp.
The features you mentioned aren't part of the Java language, they are tools used by Java language. JVM isn't part of Java as a language, they are part of the Java platform. Most people confuse the language with the platform. JVM is a tool used by the language. Even Javac isn't part of Java. It is a tool used to compile Java [1].
I doubt any Java Programmer was dragged halfway to Lisp. If it was the case, we were going to see at least 10% of those Developers finishing the trip to Lisp but we didn't. That's why Lisp remains an obscure language used by 100 people on a good day.
> Curly braces, for loops, while loops, if statements, case statements, variable declaration and initialisation etc. All those things were carbon copied from C/C++, not Lisp.
That's all minor stuff. But, even the very invention of conditional statements are originally from Lisp. http://www-formal.stanford.edu/jmc/recursive/node1.html John McCarthy proposed if/then/else and recursion to the Algol (the grandfather of C) community in 59.
> JVM isn't part of Java as a language
Historically there is no independent invention of the Java language. The Java language was developed together for and with the platform -> the JVM. Thus Java assumed on day one that it runs on a garbage collected platform.
> I doubt any Java Programmer was dragged halfway to Lisp.
There are a bunch of Java developers which struggle with Lisp-derived languages (like Clojure).
> If it was the case, we were going to see at least 10% of those Developers finishing the trip to Lisp but we didn't.
You didn't know where many of the features of the Java runtime come from or where they originated from. The originally first garbage collected language implementation was Lisp 1 in the end 50s. Here on Hackernews you can learn about it. Java (originally called oak) was explicitly designed to be garbage collected. The Java developers (Gosling) explicitly didn't want C++ like memory management.
> That's why Lisp remains an obscure language used by 100 people on a good day.
> You didn't know where many of the features of the Java runtime come from or where they originated from.
You are making a mistake of talking about tools when we are discussing programming languages. I have seen most people make that mistake with .NET platform. Java programming language isn't Java platform. In fact, as a Lisper, you should know better to dissociate the tools from the platform because Lisp is so fragmentated.
> Historically there is no independent invention of the Java language.
J++ was a Microsoft independent implementation of Java programming language. Also Java used by Android is an independent implementation of Java programming language. It doesn't contain tools which are shown on the Java platform architecture diagram I pasted on my previous comment.
GC isn't part of Lisp. Never was. Never will. It was invented as a tool to be used with Lisp. In fact, some Lisp dialects don't even have garbage collection.
Java was originally developed by SUN together with its platform. SUN did not develop Java and then later looked how to implement it. Java was specifically developed with its implementation for a few specific projects - originally set top boxes and mobile devices.
SUN didn't develop Java for Microsoft or Google - Microsoft and Google just copied parts of it years later. If it were legal, they would have copied all of it. Microsoft then mostly abandoned Java and is no longer relevant in the Java world. Same for Google, Kotlin is now their favorite language for Android development. Incompatible platforms for Java are on the way out.
> GC isn't part of Lisp. Never was. Never will.
It's like saying flying is not something birds usually do, just because there are a few birds which don't fly.
95% of all Lisp installations (including Lisp 1) use some form of automatic memory management, usually a form of GC and the language is designed to be used that way. Lisp implementations which don't use GC need extra facilities for manual memory management.
> was exxagerating to emphasize my point.
Well, it's too easy to see, that you have no idea about actual data and it kind makes your arguments exposed to be on shaky grounds.
> Java was originally developed by SUN together with its platform.
That's incorrect. Java programming language is part of the platform.
> Microsoft then mostly abandoned Java and is no longer relevant in the Java world.
Another incorrect statement. Microsoft didn't abandon Java, they were forced to abandon Java because of legal issues with Sun. That's why they created .NET. They are irrelevant because they decided to stop fighting Sun and created their own platform.
> Well, it's too easy to see, that you have no idea about actual data and it kind makes your arguments exposed to be on shaky grounds.
Lisp isn't even in the top 30. My exxageration were accurate.
> Kotlin is now their favorite language for Android development.
Google is only doing that because they were forced by Oracle. It is a forced choice.
> It's like saying flying is not something birds usually do, just because there are a few birds which don't fly.
That's not what I mean. All I am saying is that Gabrge collection isn't a feature of a programming language, it is a feature of the platform
IMO Lisp is interesting, and worth learning even if you never use it for any serious project. It falls squarely in the HN guidelines as to what is suitable to post.
Thank you. I went through the article and comments. It will be easier for me going forward because I will know that LISP is hyped because of HN's history. I didn't understand why an obscure language has so many fans here but close to non-existent in other places.
I can see Lisp is the ‘new’ React. Two years ago there were loads of articles about React, prior to that it was just Javascript. I can see people got enough of Javascript.
HN loves LISP, there's a LISP (the entire family of languages) article quite often. It's a joke that goes around here and there - the fascination with LISP in this community.
Also, I would not say there is any more hype for lisp now than 3 years ago. It's still an esoteric language to most, and one that few people actually bother learning these days.
All the javascript articles are more "practical" because a wide audience uses them, but Lisp is a language most people only use at home or at uni.
The article isn’t bad, but it also doesn’t provide you with a sustainable way to develop Lisp; interactive and incremental development together form a great proportion of value of using the language in the first place.
[0] https://github.com/rigetti/qvm/blob/master/doc/lisp-setup.md
[1] https://github.com/rigetti/qvm/blob/master/doc/editing-and-r...
(PRs are welcome!)
P.S. I should mention that I live in Emacs, but I know there are people that wouldn't touch it with a ten foot pole
- An excellent debugger and condition system!
- Code won’t be broken in 20 years (which I value when developing things like compilers). There’s one standard, and several de facto standard extensions.
- Almost 30 years of history, documentation, discussions, etc. Every corner of the language has been discussed to death.
- Several stable, mature, and independent choices of open source implementation.
- Implementations are written in Lisp all the way down. You can immediately jump to the definition of anything at any depth, and often edit or redefine to taste. (Example, I improved SBCL’s integer square root in my live image, and submitted a patch.) The only off-limits bits are a part of the runtime, like the garbage collector.
- Several independent choices of commercial implementation and commercial support.
- Generally easy to optimize and micro-optimize code. Easy to edit/disassemble/debug.
- Easy to write assembly code with SBCL.
- Fast start-up time, easy to compile into native executables. No JIT lags.
- Excellent IDE support through Emacs and SLIME. Incremental development is real with Lisp, and absolutely not so with Julia.
- Easy to dynamically generate and compile code at runtime.
- Excellent metasyntactic programming facilities. (Macros, symbol macros, reader macros, ...)
Negatives compared to Julia:
- Poor support for numerical libraries and poor support for plotting, much to the chagrin of a scientific programmer like myself.
- No hip website or hip foundation backing it.
- Quiet community, with very broad interests. Not everybody is rallying around one theme in Lisp. You got database programmers, game programmers, scientific programmers, etc. This could be a positive, if the community were larger.
I'd add even the GC is accessible if you have the knowledge. Grammarly has a blog post that talks in part about manipulating parts of the GC to achieve higher through put by keeping heap objects (I think!) from reclamation.
"Escape from the Heap: Low-Level Programming in Common Lisp" https://www.youtube.com/watch?v=S7nEZ3TuFpA
On my desktop, SBCL will compile itself from source and run the small version of its test suite in 90 seconds.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
These benchmarks may not apply for every use case, but at least they suggest that Julia is roughly as fast as compiled Lisp.
From my perspective, Lisp falls into the third tier of programming language speed.
First tier (speed wise) of commonly used or discussed programming languages on HN are C++, C, and Rust. These have the performance for almost any task but require significant development effort.
Second tier languages trade off a bit of speed for other conveniences. These include Ada, C# and Java. Definitely slower than first tier, but easier to use in their own domains of use.
The third speed tier languages are many of my favorites, for example Swift, Go, Lisp, Racket, Julia, OCaml, Haskell, Javascript, and Dart. These are still fast enough for most situations and can be very productive.
I do a lot of programming in Python3 because it is just so expressive; speed wise, it occupies the forth tier with Ruby and Lua. The relative slowness isn’t a problem for many tasks and Python is really fun to program in.
Speed isn’t everything. While in grad school, for fun, I wrote a program to generate programming language parsers. Unfortunately, this was in 1974 using punched cards and the only language that I had access to was FORTRAN IV or assembly language—both very fast languages. I never got the program to a useful level of functionality (my goal was a LALR parser generator). If I had Python, it would have been a different story.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://julialang.org/benchmarks/
https://news.ycombinator.com/item?id=19750507 (picked the discussion because combining the optimizations of two people CL got to Julia level, though Julia code is correctly written but not particularly optimized)
https://github.com/jonathanBieler/ScientificComputingBenchma...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (the more direct comparison)
And saying CL is fast because you can write in assembly is like saying Python is fast because you can write in C. And while you can't write in assembly in Julia, you can go down all the way down to the LLVM (and intercept the compiler right between detecting types and compiling so you can rewrite every intrinsic with your new backend in a more flexible way than multiple dispatch) like they did with XLA.jl for TPUs and CUDANative for GPUs.
Julia allows inline LLVM IR, so this is technically possible, if a little awkward:
https://julialang.org/blog/2017/03/piday#π-via-inline-assemb...
I better understood these layers by installing SBCL myself and playing with Quicklisp (a package manager) and ASDF (a package definition library). I wrote about this a year ago [0]. It was confusing at first. But it became clearer after exploring and writing that post. Ultimately I don't find it very different than writing a Python library with setuptools.
re: SLIME; I never ended up remembering the keyboard shortcuts as a CL hobbyist so I turned it off after a few uses and stuck with vanilla Lisp-mode. Parenthesis completion and auto-ident are the only two tools I expect of my text editor (vs. in a GUI, buttons take the place of keyboard shortcuts you must remember). I use Emacs at work and home but I hardly remember any extension shortcuts (as much as I want to benefit from projectile and magit). It even took me a few years before I felt comfortable using package-install vs. just `git clone`-ing new modes and adding their paths to my .emacs.
For all these reasons, Portacle as a distribution isn't really my style. Roswell didn't solve anything for me either once I got familiar with ASDF and Quicklisp.
Complacency on tool UX doesn't help a community. Roswell & Portacle may be a forward iteration on UX. But I also want to share the fundamentals (or at least N-1 layer down) and get other hobbyists comfortable there too.
[0] http://notes.eatonphil.com/starting-a-minimal-common-lisp-pr...
The entire point of Common Lisp is to make stuff work across implementations. You shouldn’t need to test five implementations on your development machine. The only time I can see something like Roswell (but not in its current form) being useful is an automated CI tool, but even then it isn’t really necessary.
I'm speaking of "common-lisp-controller". Which led to some problems that made avoiding distro packaging the norm.
If you have never used Emacs I would just ask the LispWorks guys for an evaluation license. It's the closest thing to experiencing one of those Lisp environments of the 80s (Emacs doesn't come close). You'll be impressed.
Could you say something about what additional features LispWorks has that Emacs doesn't?
As for Steve Losh's article, I don't recommend that one either; it recommends using a Discord server; it recommends using C libraries; it discusses performance and representation characteristics that are allowed, but not required, in interfacing with things such as graphics cards; and it has other characteristics that I don't believe someone new to Common Lisp would recognize it, so I don't recommend that article to novice Common Lispers.
Parenthetically, I don't know if it's true but I'd heard that there have been more books published on Lisp than all books on other programming languages combined.
I'd also recommend that anyone who starts out with Common Lisp give a modern Scheme (like Chicken, Racket, or Guile) a try. I found Scheme to be much more to my taste and once I learned it I viewed CL as quite backwards in many ways, so Scheme is what I use today if I can at all help it.
Finally, newbies should check out Emacs and eLisp. eLisp is more primitive than either CL or Scheme, but it's still great when combined with Emacs, which you can customize and improve to your heart's content. In addition, there's a mountain of eLisp code to build on for you Emacs improvement projects. I came to eLisp after learning both CL and Scheme, so it was pretty easy to pick up, and that's what I'd recommend others do too, just so you first learn what Lisp is truly capable of.
It only really matters if you are passing arguments to a function that both read and mutate the same variable. In idiomatic scheme that really only happens with IO or something like srfi-121 styled generators.
Umm...
Every undefined behavior in a language standard is a failure of the standard making process, and should be a source of shame. Sometimes it's politically unavoidable (because there are multiple implementations that do something different), or practically unavoidable (the best behavior is not yet known, or impossible to make precise) but every such imprecision is a landmine through which bugs, often insidious ones, can enter programs.
It wraps everything it’s own cli which, while powerful break the common interface that most developers today have become accustomed to.
I know that I would have enjoyed a good bash cli interface for managing my lisp packages using some of the notions developed in ruby / python / javascript e.g. project local installs (quick-lisp i stalls packages globally by default), project lock files for versioning, package binaries / commands (things like Rake, Rspec, NPM run scripts).
You can do all of this stuff with your lisp install it’s just more complicated and requires more steps.
Please help me understand. I am tempted to learn it but needs justification.
I won't even be surprised if LISP has a market share of less than 0.01%. Even in the US. Do you have examples of popular system built using LISP?
* https://github.com/rigetti
Google Flights is built on Lisp as well.
* https://travel.stackexchange.com/questions/87540/google-flig...
I don’t think the parent meant that experienced programmers are heavy users of Lisp, or that they use it as their main language, but rather they often know it and have an interest in it, even if it’s not paying their bills.
In my experience, which is evidently quite different to yours, excellent developers also want to increase their breadth, understand which tools are good for which jobs, and generally increase their knowledge about programming and software engineering. It’s usually the poorer engineers, experienced or not, that stick to just a few tools with no knowledge of others.
There are millions of development tools in this world. No-one has time to learn all the tools. Even if they want to. I don't understand why LISP have to be the only exception when coming to tools a Developer can ignore. I doubt Linus Torvalds has time to learn every obscure technology out there. He focuses on delivering kick-ass solutions using C. Same as other great Programmers. It is the book writers and consultants who are busy learning each and every tool.
Hardly 'book writers and consultants'. These are among the most influential people for programmers... if you had learned Lisp decades ago, you would have learned much of the basics for those newer languages: managed runtimes, evaluation, automatic memory management, programming with first class functions, virtual byte code machines, etc etc...
I have used 80% of those programming languages you listed in a professional environment and I didn't require to learn LISP. I didn't see any resemblence of LISP on any of them. To correct you, Java was heavily influenced by C/C++, not LISP. In such a way that my transition fron C++ to Java only took me few hours.
"Lisp isn’t a language, it’s a building material." - Alan Kay
> Then we should relegate LISP to an academic programming language and stop pretending that it is a major player when all the data proves the contrary. LISP failed for half a century because it isn't the best tool for the job, not because we are just stupid and only the select few have the brains for it. It is not the case. It is just not good for the job at hand -> delivering solutions.
Nobody claims that it is a major player. My claim was that it was influential - not academic, but actually practically. People like Matz (Ruby) literally learned how to implement a programming language runtime by studying Lisp, in this case the Emacs Lisp runtime.
> I have used 80% of those programming languages you listed in a professional environment and I didn't require to learn LISP.
Nobody said it's required. It's just that when you knew Lisp, you would have already known about garbage collection, first class functions, virtual byte code machines, managed memory, etc. Nothing which is directly in C++.
> I have used 80% of those programming languages you listed in a professional environment and I didn't require to learn LISP. I didn't see any resemblence of LISP on any of them. To correct you, Java was heavily influenced by C/C++, not LISP. In such a way that my transition fron C++ to Java only took me few hours.
If you don't know Lisp, how would you know which influence it had on Java? C/C++ had directly no Garbage Collection, no managed memory, no runtime code loading (-> Java class loader), ... thus these things about the Java runtime were not coming from C/C++. You got the curly braces from C/C++.
Guy Steele, who co-wrote the Java language spec: 'We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.'
And you even didn't notice it...
The features you mentioned aren't part of the Java language, they are tools used by Java language. JVM isn't part of Java as a language, they are part of the Java platform. Most people confuse the language with the platform. JVM is a tool used by the language. Even Javac isn't part of Java. It is a tool used to compile Java [1].
I doubt any Java Programmer was dragged halfway to Lisp. If it was the case, we were going to see at least 10% of those Developers finishing the trip to Lisp but we didn't. That's why Lisp remains an obscure language used by 100 people on a good day.
[1] http://sheikyerbouti.developpez.com/tmp/j2se5.gif
That's all minor stuff. But, even the very invention of conditional statements are originally from Lisp. http://www-formal.stanford.edu/jmc/recursive/node1.html John McCarthy proposed if/then/else and recursion to the Algol (the grandfather of C) community in 59.
> JVM isn't part of Java as a language
Historically there is no independent invention of the Java language. The Java language was developed together for and with the platform -> the JVM. Thus Java assumed on day one that it runs on a garbage collected platform.
> I doubt any Java Programmer was dragged halfway to Lisp.
There are a bunch of Java developers which struggle with Lisp-derived languages (like Clojure).
> If it was the case, we were going to see at least 10% of those Developers finishing the trip to Lisp but we didn't.
You didn't know where many of the features of the Java runtime come from or where they originated from. The originally first garbage collected language implementation was Lisp 1 in the end 50s. Here on Hackernews you can learn about it. Java (originally called oak) was explicitly designed to be garbage collected. The Java developers (Gosling) explicitly didn't want C++ like memory management.
> That's why Lisp remains an obscure language used by 100 people on a good day.
I have no idea where you get your numbers from.
You are making a mistake of talking about tools when we are discussing programming languages. I have seen most people make that mistake with .NET platform. Java programming language isn't Java platform. In fact, as a Lisper, you should know better to dissociate the tools from the platform because Lisp is so fragmentated.
> Historically there is no independent invention of the Java language.
J++ was a Microsoft independent implementation of Java programming language. Also Java used by Android is an independent implementation of Java programming language. It doesn't contain tools which are shown on the Java platform architecture diagram I pasted on my previous comment.
GC isn't part of Lisp. Never was. Never will. It was invented as a tool to be used with Lisp. In fact, some Lisp dialects don't even have garbage collection.
> I have no idea where you get your numbers from.
I was exxagerating to emphasize my point.
Java was originally developed by SUN together with its platform. SUN did not develop Java and then later looked how to implement it. Java was specifically developed with its implementation for a few specific projects - originally set top boxes and mobile devices.
SUN didn't develop Java for Microsoft or Google - Microsoft and Google just copied parts of it years later. If it were legal, they would have copied all of it. Microsoft then mostly abandoned Java and is no longer relevant in the Java world. Same for Google, Kotlin is now their favorite language for Android development. Incompatible platforms for Java are on the way out.
> GC isn't part of Lisp. Never was. Never will.
It's like saying flying is not something birds usually do, just because there are a few birds which don't fly.
95% of all Lisp installations (including Lisp 1) use some form of automatic memory management, usually a form of GC and the language is designed to be used that way. Lisp implementations which don't use GC need extra facilities for manual memory management.
> was exxagerating to emphasize my point.
Well, it's too easy to see, that you have no idea about actual data and it kind makes your arguments exposed to be on shaky grounds.
That's incorrect. Java programming language is part of the platform.
> Microsoft then mostly abandoned Java and is no longer relevant in the Java world.
Another incorrect statement. Microsoft didn't abandon Java, they were forced to abandon Java because of legal issues with Sun. That's why they created .NET. They are irrelevant because they decided to stop fighting Sun and created their own platform.
> Well, it's too easy to see, that you have no idea about actual data and it kind makes your arguments exposed to be on shaky grounds.
Lisp isn't even in the top 30. My exxageration were accurate.
> Kotlin is now their favorite language for Android development.
Google is only doing that because they were forced by Oracle. It is a forced choice.
> It's like saying flying is not something birds usually do, just because there are a few birds which don't fly.
That's not what I mean. All I am saying is that Gabrge collection isn't a feature of a programming language, it is a feature of the platform
https://news.ycombinator.com/item?id=20697493
or apt install cl-launch...
Also, I would not say there is any more hype for lisp now than 3 years ago. It's still an esoteric language to most, and one that few people actually bother learning these days.
All the javascript articles are more "practical" because a wide audience uses them, but Lisp is a language most people only use at home or at uni.