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.
(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.
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.
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.
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://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:
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 . 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.
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.
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.
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?
Google Flights is built on Lisp as well.
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 .
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.
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
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.