SBCL is one of the two most useful Common Lisp implementations (the other one being Embeddable Common Lisp). I wish I could permanently move to the Common Lisp / emacs universe. Unfortunately, I am stuck in this one, called "the Real World."
McCLIM has been changing a real lot, actually, as of late, with many useful changes and bugfixes and applications that use it, such as Clouseau the inspector.
For a lot of things there are portability libraries that bridge vendor extensions between implementations. So, in practice, you can use features that aren't part of the ANSI standard (threads, sockets, ffi) without tying yourself to a single implementation. Also, FFI is pretty trivial in most implementations.
Its just that open source communities have the most vocal proponents, but the closed source users tend to keep quiet and just get to work. Generalizing to some degree of course
And SBCL comes from CMUCL, most of the best parts of it are from that stellar implementation
I've been a professional user of SBCL and LW. They both have merits.
LW has better package delivery and a stellar GUI tool. LW is otherwise slow and requires non-portable APIs to get reasonable performance for some kinds of low level code.
SBCL is cheaper, way way faster (in almost every dimension), more portable, better integrated with most OS environments, and provides better static diagnostics. It suffers from having a meh garbage collector and meh delivery mechanisms.
well, SBCL is 64bit, has native threads, can be built from another Lisp, the type inferencing is improved, the whole build process is totally painless. I can build a new SBCL in under a minute from scratch using the installed older SBCL. I can install it from Homebrew on my current Mac. It runs natively in 64bit on my M1 Pro Mac. I also like the Unicode support better in SBCL.
Yes. I have deployed mobile applications using native UI (SwiftUI, etc.) with all the shared logic in Lisp. To me, this was a better alternative than the usual C/C++ shared logic approach.
My current application is a music hardware device that is mostly Lisp. As to why, this could be a lengthy post, and I am sure I have made one elsewhere on HN. It is a very good language, has many of the features that are being re-discovered and implemented in other languages, has an interactive model of development (REPL driven) that I find very productive and I can deploy an application across multiple platforms with little to no modifications.
I do pay for LispWorks and it is more than worth it. I make a living developing applications and devices that use Lisp and the cost is covered by a fraction of a percentage of sales.
Some people may try to use SBCL, CCL or other free implementations. I just don't have the time or risk tolerance to be dependent upon the lack of predictability for bug fixes or modifications needed to run on new architectures. The M1 architecture has been a big problem for some of these Lisps. CCL has no timeline for adoption and some commercial products are suffering as a result. GNU Scheme will probably never be able to run on the M1. LispWorks stays current and will fix reported bugs rapidly.
> My current application is a music hardware device that is mostly Lisp. As to why, this could be a lengthy post, and I am sure I have made one elsewhere on HN.
I was curious and stalked your profile, but I didn't come up with anything that summarized your reasoning on why you use Lisp beyond this brief statement. Perhaps you were remembering the discussion around "Some thoughts about raising the profile of Lisp" (https://news.ycombinator.com/item?id=28366292).
If you get a chance I'd love to read your take on in it. There are so few people doing active development in lisp its hard to let go of a chance like this.
Any tips for getting started doing mobile with Lisp?
Or general moving from standard development environments to lisp?
I've been interested for a long time, but never really came across examples of established developers branching our so I don't really know where to look to get started. I'm already an emacs user too, so it bothered me that way too.
The first thing I would suggest is see if using Lisp would satisfy some need that your current solutions are not. Sometimes it is hard to even know if that will be the case, because later generations of programmers may not even know what makes Lisp different from Python/C/C++/Java/etc. I would suggest reading "On Lisp" [1] by Paul Graham to get an idea of what Lisp can do. There are many other good books, but I find "On Lisp" to get to the point of what makes the language special, as opposed to other books that focus more on computer science fundamentals or topics like symbolic AI.
You will often encounter people making bullet points of why Lisp is or is not better than <insert language> here. This was me! I was a self taught programmer who grew up in the 80s using assembly language and Basic and then C and C++. The type of hardware that could run Lisp was not available to me and my career trajectory took me towards C++/Pascal/Objective-C. My first serious encounter with Lisp was using a Symbolics workstation that was sitting in a conference room at Apple. It blew my mind! I wanted to have an environment similar to that combined with what I was working on with OS X. It never happened.
Current hardware is amazingly powerful and many of the gripes people raised about Lisp are no longer pressing issues. I don't experience memory pressure or GC lags or any of the issues that used to be show stoppers thirty years ago.
You may find that Lisp is for you and it is scratching some particular itch you may not realize you even had!
I have a pretty good idea that lisp would fit into how I like to develop software.
The biggest thing that I'm looking towards lisp for is interactive programming. Python is currently my primary language, and I heavily test/prototype things in the REPL as I'm programming or dropping into one for debugging.
Additionally, I like the things you get with a complied language but have zero interest in going deep (I know them and have used them, but not professionally) with the standard C derivatives of C, C++, obj-C, and Java. I'm also pretty tired of many of the gotchas in python with its bolted-on-type system and is essentially a wrapper around C. I love the libraries and functionality, but the amount of boilerplate and testing needed to produce reliable code has burnt me out on it.
I'd probably go with Swift and SwiftUI if it weren't Apple only and still limited in what it can be practically used for, such as building deployable web services with it.
The other thing that has always lingered in my mind is the promise of DSLs/functional programming/etc. or other abstractions that never lived up to their potential ergonomically in other languages. I'd start using them but almost immediately run into edge cases that required workarounds to get working. After a while, I would abandon them entirely because the workaround added up to not being cleaner overall or leading to lower readability and maintainability.
Like function composition, I'd love to have functions that are generic work loops/data pipelines that I pass in different data and business logic/conditionals to. Still, in python, it's challenging to do that cleanly/maintainable. Or even some of the basic stuff Ruby does with metaprogramming that ends up being a nightmare to attempt in python. Even javascript does better with functional programming than python or any C derivatives.
So I have a fair sense of why I'm leaning towards lisp. I'm more interested in jumping in and using it for practical things. For example, I want to write a web API that uses SQLite. How do I prototype and test that using lisp? Kind of a “working programmer’s guide to getting going with common lisp.”
Oh, I'm also currently an independent software developer, so I don't need to worry about external constraints.
I will read On Lisp first, though! I just read the preface, and it directly addresses several of my desired outcomes.
I am working on some tools to make LispWorks easier for Emacs users, watch this space in the next few months as I finalise it.
I tend to find LW users are very comfortable with their IDE, however coming from an Emacs World, I struggled a bit.
However once I get all my best parts of Emacs into LW, I will be very happy as it is written completely in CL and together with CAPI and the readily available source code for its Editor, it can do a lot more than Emacs for Lisp Development
I have modified the LW editor to be more "Mac-like" which I guess makes me less hardcore. I am not sure a hardcore emacs user would be totally happy with the LW editor either. I have also used VS Code with the Alive plugin to interface with LW.
> I have modified the LW editor to be more "Mac-like" which I guess makes me less hardcore.
You're shipping commercial software with CL so I think you're about as hardcore as it gets :)
> I have modified the LW editor to be more "Mac-like" which I guess makes me less hardcore.
If you mean in terms of keybindings, I did the same when I did a trial recently even though I usually use Emacs for working with lisps. I think it's nice to keybindings that match most text editing programs, and I think the benefits of Emacs-y structural editing are a little overstated (in my opinion). Was just curious to hear how folks using LW do their work.
Although a huge ParEdit fan (LW has a primitive copy of it now), I tend to agree that some of the more advanced structural editing concepts are not that necessary. The basics LW already has
That said, I find Emacs to be a powerhouse, stable text editor. LW has a decent editor, but it is really hard to get to the same level of Emacs in many of the smaller aspects that you end up taking for granted and don’t want to do without
> cost is covered by a fraction of a percentage of sales
Does their licensing cost relate to your sales?
I remember inquiring some time back, and to buy the commercial version, you had to, among other things, agree to their right to audit your books, which to me seemed draconian.
Yes. I am not powering a nuclear reactor using the engine, so I can't give you any sort of hard-RTOS numbers. The kernel of the device itself uses Linux, which has been modified with "real time" patches. At some point, I'll have to publish data and benchmarks about performance to satisfy potential customers. I can say I would personally much rather use this device in a live setting than any desktop or laptop, unless I have aggressively modified the software environment of the computer. There are just too many things that can go wrong in a live setting.
> M1 architecture has been a big problem for some of these Lisps. CCL has no timeline for adoption and some commercial products are suffering as a result. GNU Scheme will probably never be able to run on the M1. LispWorks stays current and will fix reported bugs rapidly
SBCL supports the M1; lispworks and allegro still do not.
LispWorks 8.0 does support the M1. You can get a version for macOS and one for Linux. I can run the Linux version under the Parallels on my M1 Mac, too. It even supports universal binaries for macOS on the M1: LispWorks can produce one macOS application with both native Intel 64 and native ARM64 code.
You did mention above that 8.0 is now native M1, but you may still be quite right about the 7.1 version that is available for free download works using Rosetta 2 on the M1.
I do, the star mapping sofware at the core of my company is Common Lisp run by sbcl. I use it because it is fast, reliable, and a pleasure to develop with. Actually, that is true, but the actual reason I use it is that many many years ago I read PG's "On Lisp", and was blown away by it. So I had to find a project to try Lisp out. It ended up being my livelihood.
We do, in the context of a distributed embedded system.
It's great way to achieve high development velocity without compromises on runtime efficiency. I'm substantially proficient in C (we've had a bunch of systems done in it too) and there is no question we'd have missed our budget/time/features target had we chose it instead.
That said we don't use SBCL but LispWorks for delivery and CCL for development.
Interesting, I'd have assumed that LispWorks would be a much nicer development environment than CCL. Are you trying to save license fees, or do you actually find CCL nicer to work with?
No the license cost is fairly marginal in overall development costs. Rather it's an embedded system of numerous (hundreds) networked devices so it limits what kind of development and tests you can do on your laptop†. In the end you have to attach to remote images for debug sessions.
CCL happened to have threading support on Arm32 target we use so that's how the development historically started. LW license was procured later: we gave it a run and turned out the tree-shaked binaries it produces use much less memory. We're comfortable running it on a 128Mb RAM (single core) SoM as a part of embedded Linux build.
† That said we do have a simulator for the product running on a 64c/128t server. It however mostly tests deployment/procurement/networking part of the thing rather than physical component it operates on.
The threading support was lacking on SBCL, that's the reason we started on CCL. It is of course there on LW or we wouldn't be able to deliver.
Point is if I have to attach to remote hosts anyway I might just as well continue to use Emacs Slime rather than learn the ropes of LW's own remote debugger. Also LW license allows for unlimited redistribution of deliverables (that you can't however attach to) but the compiler itself is licensed per seat.
> Clojure code is incredibly dense. If I have a file with 30 lines of code, it might as well be 1000 lines of java. I’m not exaggerating. The code does a whole lot in a few words and once you’re comfortable with Clojure, man you can whip out a web service really fast ... You will never want to program without a REPL again ... Clojure isn’t just function-oriented in its syntax; it can be object-oriented, and stack-oriented, and array-oriented, and so on–and mix all of these styles freely, in a controlled way. If you don’t like the way the language fits a certain problem, you can write a macro which defines a new language, specifically for that subproblem.
Is Clojure considered a net positive for bringing more funding and developers into the family of Lisp dialects? Do Clojure developers graduate to CL?
I worked at Hotelicopter, which was a hotel meta-search engine written in Ruby on Rails. We were bought out by the six major hotel chains in the US and re-branded as Roomkey.com. To get us started, they agreed to push a lot of traffic at us. We knew from load testing that it would be very difficult, with our practically non-existent ops team, to scale Rails to handle 1000x our current load.
We knew we had to rewrite the system in a more scalable language, and we had to be live on a fixed date. This was late 2010, early 2011. Our CTO evaluated a number of languages and chose Clojure. A team of five or so devs was able to write the entire system in a few months and launch without problems. I don't think that would have been possible in a non-lisp language.
The Clojure learning curve was steep, especially since stack traces for anonymous functions in Clojure 1.1 often began with "nil pointer exception, no source file, line 0."
Once our dev team "got" Clojure, we were hooked. The verbosity of other languages started to look appalling. Clojure let us iterate quickly without sacrificing performance, which was suddenly a big issue.
Writing Lisp code permanently changed the way I think, and the way I code in other languages. I strongly prefer composing short, deterministic functions, which are testable and easy to reason about.
Roomkey became a victim of the pandemic, when hotel bookings declined sharply.
I'm just now starting to pick up Common Lisp, and it's a joy: the simplicity and consistency of the language, the REPL, the emacs integration. I also like that it compiles to native code. That's good for performance and for deployment, since it doesn't require the target machine to have a JVM.
I've worked at two different Clojure companies now.
My take is that yes, Clojure is strictly better than, say, Python. It is strictly worse than Common Lisp. A lot of stupid BS just goes away when you're not papering over an underlying runtime. Yet, the Common Lisp community has struggled with what I'll genteely call "ergonomics of modern development"; i.e, the language contortions to do some boring normal things, particularly around hashmaps, are a PITA. Clojure addresses that nicely. However, if a serious startup went into Common Lisp, those things would be addressed internally in a few months (hopefully they'd release the library).
The angle where Clojure really wins is access to JVM libraries. Just, no contest.
Clojure as a hiring strategy is strategically problematic. It's niche, a lot of people won't know it, and some really smart people will do some gnarly hacks for your company starting out. The implication is that later on, you have to unwind the hacks, new people have to go through a deconfusion period, and the smart people will move on leaving you with gnarly code to untangle. I do not expect this to be different for Common Lisp companies.
Would I build a team on Common Lisp? Yes, but I would not plan it in such a fashion that I would expect the team to get large, or for the entire company to have to interact with their codebase. I'd apply similar calculus to Clojure, I just don't think its as good as CL.
If I really needed the JVM libraries, I'd be doing the project in Scala.
Too, if I really needed a strong reliable software pipeline, I'd be doing the project in a strongly typed non-dynamic language: Scala, Rust would be my preferred goto languages.
I love Common Lisp, but frankly the purists are wrong on this. Clojure is a damn sight more of a lisp than any other even remotely common language. My preference now leans CL, but Clojure is a joy in its own right, with some of the nicest little touches I've seen in a language.
Why "more of a lisp"? I guess it depends on your personal definition of what a lisp is. For example, I'm much more interested in Racket because my interest is computer science.
I meant more along the lines of dynamism, s-exprs, metaprogramming, a first-class REPL, that sort of thing. Clojure is a weird lisp for sure, but it's certainly more similar to Scheme than, for instance, Java, Python, or Go (let alone Rust). Not sure what you mean by that last part, care to clarify?
Oh yeah no I meant compared to frequently used languages. Racket's great too, though I didn't love the REPL. Clojure is definitely an odd one out in the lisp family, but compared to anything else on the JVM it's a lisp through and through.
Kind of, a Python REPL is nothing more than a live Python environment. You type some Python code and you immediately see the result. The main idea behind a REPL is to speed up the feedback loop of write code -> execute code -> verify results -> modify code -> repeat.
The simplest REPL you're probably familiar with is a separate window where you can execute some Python code which you can then copy paste into your editor where you can polish it. This is helpful, but a REPL (even the Python REPL) can do more.
For example a nice IDE for python or lisp lets you execute selected pieces of code with a single keypress. You immediately know whether it works, and you can try out your snippet with different inputs to quickly test it etc.
You'll often make a modification or two after checking your code in a REPL, and good IDEs will let you replace the original snippet with your modified snippet with one or two key presses.
REPLs tend to be a little bit nicer if they're well integrated into your program, for instance you can load parts of your program, or start a REPL with a breakpoint in the middle of a program to debug your code from within a REPL. Again, intelligent IDE integration makes this really cool!
In the case of many Lisps, REPLs have even deeper functionality. You get features like automatically being thrown into a REPL when an error happens, so you can rewrite the code and pretend the error never happened and run it with the updated version. This is even possible in live code! (I believe some lisp code running in a space device at some point was updated from within a REPL in this way? While it was in space!)
I believe there is even more to it than that, but I've never gone deeper than this.
The old Python support for Emacs was such very good support for true REPL driven development. I have been using Lisp languages professionally since 1982, so I am fussy about having good REPL support.
I usually use PyCharm Pro and VSCode when I have to use Python for work gigs (I do deep learning about 100% of the time now), but when I want a great REPL experience I flip over to Emacs.
It's like the prisoners of Plato's cave. One could describe it to you but it's nothing like trying it. I would suggest you look for some videos or blog explaining it, or take a a week-end to try. The term REPL is here deceptive. You can load the whole compiler and the whole program in memory in a server accepting code changes and interact with them iteratively and have transparent incremental compilation when editing the code.
> I know it doesn't want to be a serious language, but rather a toy for academic types
Only "experimental" status on Windows is definitely unfortunate for Windows SBCL users.
However, today in 2022, the server world has been eaten up by Linux. Few if any production server deployments would run on Windows -- there definitely might be some major ones but an overwhelming number would deploy to Linux. Then there would be a lot of developers that run Linux in a Virtual Machine, dual boot, use WSL/WSL2 or have a dedicated Linux machine.
There is also a influential but niche developer crowd that runs MacOS.
What I'm trying to say is that not having full support for Windows hardly implies "[SBCL] doesn't want to be a serious language, but rather a toy for academic types."
A statement like this may have been true in 2000. Not in 2022.
Windows is no longer the most important platform for people who either develop software or deploy software to servers.
I am not trying to criticize Windows in any way. It's just the reality that a big chunk of development action is taking place on Linux (and in a niche way on MacOS) today.
I don't know how true this is. Windows Server is massive in the enterprise corporate world. My first job as a system tech was spent exclusively on Windows machines across numerous large companies, and I've worked at several companies since that are Microsoft shops deploying to Windows Servers.
I never implied that Windows Server is not significant. It would definitely have a lot significant deployments. The absolute number of deployments would also be quite large. But I can bet that this will pale in comparison with Linux. Think about it -- all major cloud providers use Linux as a building block to provide their services. Their clients probably use Linux for deployment too.
My objection was to the statement that "[SBCL] doesn't want to be a serious language, but rather a toy for academic types". And to that I implied that Windows is no longer as dominant in 2022 as it may have been, say, in 2000.
SBCL is an open source, non-commercial, project. That means it largely depends on volunteer effort to get anything done and if the volunteers are insufficiently interested in or focused on Windows, you get the current result.
If you do want Windows support for Common Lisp, happily it exists! But primarily from the commercial CL versions, LispWorks and Allegro CL.
We used SBCL on a commercial medical AI project about 12 years ago, and we paid a monthly support stipend to a SBCL maintainer - really worth the money! I forget the guy’s name but he was there for us the few times we needed him.
Thank you. I'm sorry I was harsh, but I just spent a frustratingly long time getting Sketch to work on Windows, but I did it. MSYS2 to compile a missing lib was the missing piece that did it. I'm frustrated, but not giving up.
It's experimental because few of the developers (and few SBCL users) are on Windows, so it's possible more bugs slip through. Developing on Windows is terrible, so it's no surprise volunteers don't want to spend their time doing it.
FWIW, I've used SBCL on Windows, and never had any problems. I wasn't using CFFI, POSIX, threads, or things like that, so that probably helped.
"Developing on Windows is terrible"
I presume you meant "developing SBCL" on Windows is terrible? Windows is a pretty good development platform nowadays with modern tooling - but it's certainly different than posix environments.
To clarify my position, my work include maintaining and developing a cross platform native codebase that serves Linux, Windows and macOS, in a global setting.
I find each platforms native toolchain good in their own way. Each has it's particular quirks. The thing is that when you learn the quirks on one platform, the other platform has other quirks - hence it likely feels "worse" for a while, when in fact, it's just "different".
It sounds something is not right. ReSharper occasionally puts everything to a halt.
If you office policy allows, try disengaging it. A few versions ago Visual Studio had lots of missing features that ReSharper provided instead, but in 2019 and 2022 the gap is considerably smaller.
I am using visual studio daily and 2022 is particularly snappy.
Also - In work setting some end point policies enforce anti-virus software that converts the system to an unbearably slow state.
If you prefer posix tools for command line use (IMO they are much more ergonomic than powershell) wsl2 works pretty well for grepping and such.
Add WSL2 and it's pretty much there (if not better because of both worlds) and that's coming form someone who works exclusively nowadays on Mac, ChromeOS, and Linux.
I was under the impression that most/all of the commercial lisps were quite windows centric? Now there does tend to be a connection between Foss software and Foss operating systems.
Both Allegro CL and LispWorks originally are coming from the UNIX world and they still support various UNIX variants: Linux, Freebsd, macOS and Solaris. Both support Windows. LispWorks also has runtimes for Android and iOS/iPadOS.
LispWorks has a very good native Macintosh development environment as well as the CAPI interface library, which enables one to develop apps that use native widgets on multiple platforms. I do much of my development on my Mac for an application that is deployed on Linux.
I work on several systems where windows is poorly supported. In general it's because everything else is POSIX(ish).
Even though I use windows as my OS, I do most of my coding in WSL, so I still don't need a true windows version of things I work on.
True windows support in my experience usually requires paying someone (unless you are doing something graphical, where Windows often is the best choice).
