[HN Gopher] SBCL: New in Version 2.2.1
___________________________________________________________________
SBCL: New in Version 2.2.1
Author : susam
Score : 89 points
Date : 2022-01-30 17:35 UTC (5 hours ago)
(HTM) web link (www.sbcl.org)
(TXT) w3m dump (www.sbcl.org)
| alexott wrote:
| it would be really useful to add release dates to this page...
| rjsw wrote:
| Today is the last Sunday of the first month of the year.
| stassats wrote:
| Ok, I added the dates.
| alexott wrote:
| Thank you
| labrador wrote:
| dang wrote:
| Please don't take HN threads into programming language
| flamewar. That's one of the things we most don't want here, and
| it's easy to avoid.
|
| https://news.ycombinator.com/newsguidelines.html
| Jtsummers wrote:
| 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.
| labrador wrote:
| 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.
|
| https://github.com/vydd/sketch
| e12e wrote:
| 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.
| lispm wrote:
| 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.
| diskzero wrote:
| 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.
| lispm wrote:
| The IDE and CAPI runs on all their desktop platforms: via
| Windows, macOS and GTK+.
| diroussel wrote:
| It's common that many languages find windows support hard as
| it's so different to all the unix-like operating systems.
|
| Node.js used to have patchy support for Windows. It took time
| and investment from Microsoft themselves to fix that.
| stassats wrote:
| Where does it say that?
| pjmlp wrote:
| Windows is pretty much tier 1 for Allegro and Lisp Works, you
| get what you pay for.
| jlarocco wrote:
| 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.
| fsloth wrote:
| "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.
| fsloth wrote:
| 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".
| exdsq wrote:
| 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.
| rscho wrote:
| CJefferson wrote:
| 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).
| rjsw wrote:
| I deliver a product using SBCL on Windows, it works fine but
| I'm not using any features that might cause problems like
| threads or external libraries.
| sidkshatriya wrote:
| > 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.
| exdsq wrote:
| 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.
| sidkshatriya wrote:
| 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.
| walterbell wrote:
| What does the Common Lisp community think about the adoption of
| Clojure and ClojureScript by "knowledge graph" companies like
| Roam Research and clones like Obsidian
| (https://news.ycombinator.com/item?id=28894481) and Athens
| (https://news.ycombinator.com/item?id=26316793)?
|
| 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?
| diamondap wrote:
| 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.
| ravi-delia wrote:
| 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.
| rscho wrote:
| 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.
| ravi-delia wrote:
| 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.
| exdsq wrote:
| 'More of a lisp' than other common languages is what I
| understand it to mean, not more of a lisp than Common Lisp
| or Racket.
| pnathan wrote:
| 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.
| bnjms wrote:
| > You will never want to program without a REPL again
|
| 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?
| azeirah wrote:
| 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.
| Kototama wrote:
| 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.
| vmsp wrote:
| Is there anyone here using CL in production? If so, why --
| compared to more mainstream solutions -- and how's your
| experience been?
| rjsw wrote:
| I am, it is easier to write than C or C++ and faster than
| Python or Ruby.
| mmmm2 wrote:
| Grammarly, at least as of November, 2020:
| https://www.grammarly.com/blog/engineering/running-lisp-in-p...
| diskzero wrote:
| 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.
| jpe90 wrote:
| Do you use emacs the lispworks editor, or something else for
| coding?
| math-dev wrote:
| 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
| jpe90 wrote:
| I'm excited to see it!
| diskzero wrote:
| 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.
| jpe90 wrote:
| > 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.
| math-dev wrote:
| 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
| moonchild wrote:
| > 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.
| lispm wrote:
| 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.
|
| SBCL is native on the M1, too.
| diskzero wrote:
| > 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?
| moonchild wrote:
| It runs the x86 version under rosetta. I expect most
| lisps will run the same way.
| diskzero wrote:
| 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.
| diskzero wrote:
| It looks native Apple Silicon to me, but maybe you have
| information I don't.
|
| >>> 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
| moonchild wrote:
| Ah, right you are; looks like my information was out of
| date. http://www.lispworks.com/news/news39.html says:
|
| > Native support for Apple silicon Macs
| solarmist wrote:
| 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.
| fiddlerwoaroof wrote:
| These people are: https://www.itasoftware.com
| varjag wrote:
| 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.
| patrec wrote:
| 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?
| varjag wrote:
| 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.
| patrec wrote:
| But doesn't lispworks also have threading support on arm
| and would allow you to attach to a remote image?
| varjag wrote:
| 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.
| smegsicle wrote:
| No reason not to, unless you can't trust your developers with
| high-power footgun features like.. multiple dispatch ??
| vindarel wrote:
| See: https://github.com/azzamsa/awesome-lisp-companies/
|
| (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)
| juanre wrote:
| 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.
| Koshkin wrote:
| 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."
| math-dev wrote:
| Lisp Works is way better than SBCL ;)
|
| 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
| lispm wrote:
| There are quite a bit improvements in SBCL over CMUCL. I like
| it.
| math-dev wrote:
| Anything in particular? Its something I have searched the
| web before, but not much information on the topic
| lispm wrote:
| 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.
|
| CMUCL is still 32bit, AFAIK.
| pjmlp wrote:
| I consider Allegro and Lisp Works more useful, as they are
| closer to the original Lisp Machine/Interlisp-D development
| experience.
| lispm wrote:
| Load McCLIM into SBCL. See https://github.com/McCLIM/McCLIM
| or https://mcclim.common-lisp.dev
|
| It's available also via Quicklisp.
| tut-urut-utut wrote:
| Too bad this GUI framework doesn't work on the most
| widespread end user OS.
| lispm wrote:
| Why not? Isn't there X11?
| rjsw wrote:
| Please provide a proposal on which UI API a Windows build
| of McCLIM should target.
|
| This is a serious question. What is the best way of
| putting lines and text on the screen on a modern version
| of Windows?
| pjmlp wrote:
| Win32 should suffice.
|
| You put lines with Direct2D and text with DirectWrite.
| pjmlp wrote:
| Yeah, I guess it has hardly changed, right?
| phoe-krk wrote:
| 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.
| pjmlp wrote:
| Thanks, I guess it is worth a revisit.
___________________________________________________________________
(page generated 2022-01-30 23:01 UTC)