SBCL: New in Version 2.2.1
sbcl.org
sbcl.org
It's available also via Quicklisp.
This is a serious question. What is the best way of putting lines and text on the screen on a modern version of Windows?
You put lines with Direct2D and text with DirectWrite.
They should really appear in README.md!
So in short, yes, except for any third party libraries
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
CMUCL is still 32bit, AFAIK.
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.
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.
SBCL supports the M1; lispworks and allegro still do not.
I have been using LW on the M1 for months. Why do you think Apple Silicon is not supported?
>>> file lispworks-8-0-0-macos64-universal lispworks-8-0-0-macos64-universal: Mach-O universal binary with 2 architectures:
[x86_64:Mach-O 64-bit executable x86_64]
[arm64:Mach-O 64-bit executable arm64]
lispworks-8-0-0-macos64-universal (for architecture x86_64): Mach-O 64-bit executable x86_64
lispworks-8-0-0-macos64-universal (for architecture arm64): Mach-O 64-bit executable arm64
> Native support for Apple silicon Macs
SBCL is native on the M1, too.
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
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.
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
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.
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!
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 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.
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.
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.
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.
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.
(to everyone answering: is your company listed there?? Thanks in advance)
See also this recent interview: https://lisp-journey.gitlab.io/blog/lisp-interview-kina/
(and I also do for a DB-management script and a simple webapp)
May 2020, https://athensresearch.ghost.io/why-you-should-learn-clojure...
> 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?
E.g. a S-exp-ified version of C is "more of a Lisp" than standard C, like:
Evidently, it has something to do with "a joy" to use, not with objective attributes like the details of how things work: symbols, lists, Booleans.
Also, the grandparent makes no hint of this issue at all; ravi-delia isn't responding to anything in the grandparent comment.
I’m not a programmer. What does this mean in terms of Python? Does one write code in the repl then export it to a file to Polish when done?
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.
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.
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.
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.