8 ms·
Wow, wasn't expecting to see my post on here! Eventually, I want to write a follow-up, but I'm still a beginner. Here's what I've liked about Common Lisp so fa
by schemescape 3y ago
Wow, wasn't expecting to see my post on here! Eventually, I want to write a follow-up, but I'm still a beginner.
Here's what I've liked about Common Lisp so far:
* The condition system is neat and I've never used anything like it -- you can easily control code from afar with restarts
* REPL-driven programming is handy in situations where you don't quite know what will happen and don't want to lose context -- for example parsing data from a source you're unfamiliar with, you can just update your code and continue on instead of having to save, possibly compile, and restart from the very beginning
* Common Lisp has a lot of implementations and there's a good deal of interoperability -- I was able to swap out implementations to trade speed (SBCL) for memory usage (CLISP) in one case (multiple compatible implementations is one of the reasons I've been leaning towards CL instead of Scheme for learning a Lisp)
* Even as an Emacs noob, the integration with Common Lisp is excellent, and it works great even on my super slow netbook where I've been developing -- this isn't as big of an advantage these days with fast computers, VS Code, and language servers, but it's definitely retrofuturistic
There's also a few things I don't like:
* The most popular package manager (QuickLisp) is nice, but not nearly as featureful as I've become accustomed to with newer languages/ecosystems
* Since the language itself is frozen in time, you need lots of interoperability libraries for threads, synchronization, command line arguments, and tons of other things
* I really, really wish SBCL could support fully static builds, to enable distributing binaries to non-glibc Linux distributions
I'm sure there are more pros/cons, but that's what came to mind just now.
- atgreen 3y agoCheck out ocicl as an alternative to quicklisp!
- tgbugs 3y agoFor static builds, if you're willing to run a slightly older version of sbcl daewok's work on building and linking sbcl in a musl environment might be solution you're looking for. I've tried to port his patches to more recent versions but there are segfaults due to changes in upstream. https://www.timmons.dev/posts/static-executables-with-sbcl.html https://www.timmons.dev/posts/static-executables-with-sbcl.h... https://www.timmons.dev/posts/static-executables-with-sbcl-v2.html https://www.timmons.dev/posts/static-executables-with-sbcl-v...
- schemescape 3y agoYes, I did see that, but I was scared off by having to apply patches :)
- mark_l_watson 3y agoThanks for your write up. I am looking forward to the next installment.
- schemescape 3y agoThank you for your Lisp books! I like your pragmatic approach of using Lisp where it makes sense and not being afraid to shell out to something else where appropriate (among many other nuggets of wisdom).
- chlorion 3y agoI have some cons! Last time I checked on it, QuickLisp doesn't support fetching packages over anything except for plain http, with no encryption and no verification mechanism in place to detect files that may have been tampered with during transmission. I think not supporting encryption or authentication for something as important as fetching source code makes QL a non-starter for me and hopefully for anyone else who cares about security. Another issue I have ran into, is that SBCL is hosted on sourceforge, which has in the past injected malware into projects downloadable archives! I consider this to also be a security issue, and sourceforge in general is not pleasant to work with. I don't think there are any valid reasons to continue to use sourceforge today, so why such an important project continues to use it confuses me a lot. I don't see these issues mentioned by anyone else which is bizarre to me. I really like lisps and common lisp specifically but things like this has driven me away from using it and it doesn't appear that anyone cares about fixing these things.
- schemescape 3y agoQuicklisp doesn’t use TLS or signatures? How have I not heard this before? That would be unbelievably irresponsible. Has this really not been addressed by the CL community? Edit: here’s the issue: https://github.com/quicklisp/quicklisp-client/issues/167 https://github.com/quicklisp/quicklisp-client/issues/167 Thanks for bringing this up!
- koito17 3y agoThe reason for this is quite simple: portability. Quicklisp also uses plain TAR files to distribute dists. Why? Because quicklisp has a built-in TAR extractor written in 100% standard/portable CL. This allows Quicklisp to run on just about everything, from your computer to real LispMs and operating systems like Mezzano. TLS comes up every time someone discusses Quicklisp, but nobody bothers to go ahead and actually implement it portably (and even if they did, have fun with performance and side channel attacks, both of which require you to break portability to implement well for every platform you want to target). If you would like a more stereotypical package manager, consider using CLPM. Though one of the big reasons to use CLPM is not encryption IMO, but versioning. ASDF supports locking versions of dependencies, but Quicklisp doesnt ever use this and instead constantly pushes latest of everything from git repositories. This IMO sucks a lot more than using plain HTTP given that this actually breaks code, whereas some MITM from plain HTTP connection to Quicklisp would require so much coordination (and specificity of target) that it's just not in my threat model at all.
- matrix12 3y agoI will give you a cons. https://cons.io https://cons.io Gerbil/Gambit scheme are fully static binary generating alternative to CL.
- schemescape 3y agoI’ll take a look, thanks! My biggest concern with Scheme is that each implementation seems to have its own ecosystem due to subtle incompatibilities. From an outsider’s perspective it seems a lot more fragmented than CL. Not necessarily a big deal if you have the libraries you want, but it gives me pause.
- bitwize 3y agoR7RS, which Gambit (mostly?) supports, helps mitigate this by making library code more portable across implementations. Gambit, in particular, can also very easily take advantage of the wide variety of C libraries; it has one of the easiest, most integrated FFIs of all Scheme implementations.
- keithalewis 3y agoI cdr car less about your cons. Seriously though, mad props for being diligent enough to spend your attention on this. There is a lot to learn from people who came before us and build on that.
- mrcode007 3y agoSBCL supports static builds by saving core with runtime into an executable file you can then copy around at will.
- schemescape 3y agoDo they work across glibc verisons or musl libc? My understanding is that they do not.
- easeout 3y agoLove your site's CGA vibes.
- schemescape 3y agoThat is exactly what I was going for!
- distcs 3y agoMaybe I'm missing something. What about the site is giving CGA vibes?
- wott 3y agoThe 4-colour palette with cyan and magenta.
- CodeCompost 3y agoSmall typo enusre => ensure
- vindarel 3y ago> lots of interoperability libraries That's true. For cases when you want to start with a good set of libraries (json, csv, databases, HTTP client, CLI args, language extensions…), I am putting up this collection together: https://github.com/ciel-lang/CIEL/ https://github.com/ciel-lang/CIEL/ It can be used as a normal Quicklisp library, or as a core image (it then starts up instantly) or as a binary. It can run scripts nearly instantly too (so it isn't unlike Babashka). We are ironing out the details, not at v1.0 yet. > handling a runtime error by just fixing the broken code--in-place, without any restarts [from the blog] Also (second shameless plug) I should have illustrated this here: https://www.youtube.com/watch?v=jBBS4FeY7XM https://www.youtube.com/watch?v=jBBS4FeY7XM We run a long and intensive computation and, bad luck, we get an error in the last step. Instead of re-running everything again from zero, we get the interactive debugger, we go to the erroneous line, we compile the fixed function, we come back to the debugger, we choose a point on the stackframe to resume execution from (the last step), and we see our program pass. Hope this illustrates the feature well!
- TheOtherHobbes 3y agoLISP continues to be a very interesting language. But REPL development is a mixed blessing. There are many situations where you want to start from a blank slate with no previous state. LISP would be a more practical language if it included a trivial option to make that possible.
- ColonelPhantom 3y agoIn that case, can't you just restart the REPL? Or give the program a main function that you run?
- realharo 3y agoWon't you also be more likely to write code based on data that you happen to have in the current situation, but not for data that covers every situation? E.g. code that accesses an optional property as if it was always present, because it happens to be present when you're writng the code, etc. That seems like a possible pitfall when relying on a REPL heavily, but I haven't used such a language myself, so can't speak from experience.
- aidenn0 3y agoAnd with TDD, aren't you ore likely to write code based on the current tests you have, but not code that covers every situation? Any time writing code, you (should) aim for the general situation and then test it with whatever edge-cases you think of at the time. The REPL lets you live-test. I know many people who dump their REPL history to a file and turn them into tests.
- realharo 3y agoMy point was, having an actual example of data in front of you, instead of only definition of the structure/schema/interface/type of the data could push people more towards relying on things specific to that example. Especially in dynamically typed languages, but also for things like trying to take the first element of a list that might be empty (in languages where that doesn't return an `Option`), etc. And I wonder whether someone observed that in practice.