4 ms·
I have been using Common Lisp professionally for over a decade. Largest codebase was probably ~100k lines for an embedded optical fingerprint analysis and booki
by reikonomusha 5y ago
I have been using Common Lisp professionally for over a decade. Largest codebase was probably ~100k lines for an embedded optical fingerprint analysis and booking system for US law enforcement agencies. The largest Lisp team I've worked on was about 30 people for satcom hardware.
Every time I've described to people on the internet what makes Lisp nice, I've been met with a riposte that such aspects aren't unique to Lisp—be them interactive/incremental development, macros, efficient machine code, editor integration, whatever—or that a laundry list of features means nothing and instead Lisp's value should somehow be proven through its (hitherto comparatively dismal) popularity with employers and software engineers. I myself have definitely given up on an academic approach to proselytizing the language, and instead have just focused my energy in building applications and libraries people (especially employers) find useful, at smaller cost and in shorter time than other people are able to provide.
It's like classical music. I can't convince you such music is incredibly rich and pleasant, especially not by talking about the harmonic theory of common practice. Instead, you just have to listen and agree or disagree, I think.
And Lisp certainly has no secrets; it's old as can be and extraordinarily and thoroughly documented. Countless people (myself included) have spilled ink on the (alleged) virtues of Lisp. It's all out there.
When it comes down to it, it's an incredibly flexible language useful for prototyping and rapid development, while at the same time supporting everything you need to transform your application into a rock solid, robust, static binary. All of Lisp's features balance in such a way that developer time and energy are prioritized and consequently optimized.
P.S., Like a sibling comment mentioned, you can have Haskell-level static typing in Common Lisp with Coalton: https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton
- someguy101010 5y agohow do you go about producing static binaries for sbcl?
- reikonomusha 5y agoLoad your application up in SBCL and call `save-lisp-and-die` with the options you want (like what the `main` function should be).
- fmakunbound 5y agohttp://www.sbcl.org/manual/#Saving-a-Core-Image http://www.sbcl.org/manual/#Saving-a-Core-Image
- deleted 5y ago[deleted]
- d110af5ccf 5y agoYou don't. As others noted, you can save a core image. Cross compiling, tree shaking, and other such things don't exist in the sbcl world and (from what I've read in the past) the people developing it have little or no interest in those features. If you need those sorts of features paired with common lisp you could give embeddable common lisp a try. Otherwise if any lisp language will work for you then chicken scheme and gambit scheme both compile to c.
- moonchild 5y ago> tree shaking The technique of 'tree shaking' was originally developed for lisp.
- d110af5ccf 5y agoAnd? When I last checked sbcl didn't support it. Are you implying that has changed? Neither did sbcl support cross compiling. To the best of my knowledge all you can do with sbcl is save an image. When I was looking in to this I read through many discussions where the developers appeared hostile to the idea of implementing these features. A common refrain I encountered was that tree shaking is unnecessary because the core images are compressed.
- reikonomusha 5y agoYou can delete data from the image if you want. We used to do it: scrub all doc strings, inlining data, etc. It's trivial. In 2022, removing a few megabytes of data doesn't seem worth the maintenance cost of the feature. In other words, for most users, it's a non-problem.
- oblio 5y agoTree shaking isn't data removal, it's dead code removal. And assuming he doesn't want what he wants is kind of in bad taste. You don't know his requirements.
- vindarel 5y agoLike this, it's easy: https://lispcookbook.github.io/cl-cookbook/scripting.html#with-asdf https://lispcookbook.github.io/cl-cookbook/scripting.html#wi... (save-lisp-and-die run from a terminal)
- rayiner 5y agoCommon Lisp is just tastefully designed. Part of it is the language itself, but also the libraries, and the culture around it. Even tiny things like underscores-in-variable-names versus camelCaseVariableNames has knock on effects like encouraging descriptive names. It’s hard to distill it into just one feature.
- smegsicle 5y agohyphenated-names also makes it much easier to see and remember whether you split something that might be a compound word- did i call it hotDog or hotdog? while hot-dog jumps out as more distinct and harder to mix up with hotdog plus the canonicalization as ALL-CAPS makes it easy to point out SYMBOLS among the prose of documentation edit: and people make fun of it for having like six equality functions, but at least it's only got one false value
- bitwize 5y agoI don't think it's just the features of Lisp, but rather how they interact. One thing I realized about Doom (1993 video game) is that -- sure, it's got scary monsters and cool weapons, but what really makes the game awesome is how these elements interact with each other. For example, an Imp has just enough health to be taken down with one shotgun blast, so in the early stages of the game, getting anything stronger than the pistol will be a priority when you encounter a pack of Imps. And a Cacodemon is very dangerous, but it has a high chance to stun, so you can pretty safely kill it by stun-locking it with a rapid-fire weapon like the chaingun. The way the monsters behave, together with the terrain, allowed the developers to combine just a few elements to create a huge variety of combat situations that pretty much required the use of every single weapon, and a variety of skills and strategies from the player. And, not only did this make Doom a more exciting game to play, it opened up an enormous possibility space for user-generated content that a dedicated fan base is still exploring nearly three decades later. Lisp is like that. It's not just that it has a REPL, or macros, or homoiconicity, a fast compiler, incremental development, or that the evaluator is itself built into the runtime -- it's that it has all those things, they compose nicely, and they interact in such a way that it opens up a tremendously huge possibility space to even a single programmer that other languages do not. Could you countenance writing an expert system in Java? It's possible, but it would be tedious work. And Lisp's dedicated fans are still exploring that space today, six decades later.
- bcrosby95 5y agoI completely agree, many people look at a language as the sum of its features, but it really isn't. Also, I think Lispy syntax is key in REPL ergonomics. It means you can, more often than not, take a chunk of code and trivially insert it into the REPL.
- reikonomusha 5y agoYeah, I absolutely agree. It really isn't about the laundry list, but how the parts come together to form a whole. But I understand that, to many, it still sounds handwavy and nondescript. The Doom comparison is great; I'll keep that in my pocket.
- wglb 5y agoI wonder if there isn't a generally distributed congenital allergy to parentheses.