14 ms·
A Road to Common Lisp
- TurboHaskal 8y agoThis is a godsend. Probably the best introductory article on Lisp to date.
- bunderbunder 8y agoI haven't read the whole thing, but, I gotta say, seeing the "Ugliness" section (http://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#ugliness http://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#ugl...) in the preamble gives me high hope for this writeup. It's so lovely to see writing on Lisp that isn't just hagiography.
- Syzygies 8y agoYes. I don't mind the parens (syntax highlighting can subdue them), but every time I actually fire up Common Lisp to try it, I see all caps somewhere, like someone even older than me is shouting at me, or I stumbled across a box of my Fortran punched cards from before I switched to APL in the 1970's. That's an ugliness not addressed by this guide.
- stevelosh 8y agoYou can try to make it less shoutey by messing with readtable-case[1] but in my experience that's more trouble than it's worth. I found the uppercase a bit obnoxious at first too, but it's grown on me over time and now I find it quaint. [1]: http://clhs.lisp.se/Body/f_rdtabl.htm http://clhs.lisp.se/Body/f_rdtabl.htm
- phyrex 8y agoBecause you can just turn it off? https://www.cliki.net/Case%20sensitivity https://www.cliki.net/Case%20sensitivity
- rjsw 8y agoAllegro CL can be configured to be case sensitive [1]. [1] https://franz.com/support/documentation/10.0/doc/case.htm https://franz.com/support/documentation/10.0/doc/case.htm
- lisper 8y agoThere is a good reason for this "ugliness": it makes it easier to distinguish the things that you typed in vs the things that Lisp printed out. Nowadays we can make these distinctions with fonts, but back in the teletype days this was a really useful feature. Yes, the teletype days are over, but teriminal.app still exists and there are situations where interacting with Lisp directly through a terminal is useful, and so this feature can still be useful even today. Like the parens, it takes a little getting used to, but once you're used to it, you'll miss it when it's not there.
- deleted 8y ago[deleted]
- pjmlp 8y agoYes, the same reason why all Wirth languages use uppercase for keywords. And not a big deal on the age of automatic code formatters.
- deleted 8y ago[deleted]
- rauhl 8y agoThat’s just the default. You can always put (setf *print-case* :downcase) in your .sbclrc (or whatever the equivalent is for your implementation) and never have to see all-caps again. And yeah, the default upcasing is ugly and inelegant, but they were trying to support the caps-only machines & code still in use at the time. It’s one of the key things I’d change in a modern Lisp standard. But you have to admit: when the default print-case is one of the worst things in a language, that language is doing pretty well.
- Tcepsa 8y agoTIL! Thanks for pointing this out; it makes me feel much better than my previous assumption that all these people running around proclaiming the greatness of CL were just _okay_ with the allcaps!
- krmboya 8y agoThanks for this guide, I'll keep referring to it often. My current road to Common Lisp is working through Peter Norvig's book Paradigms of Artificial Intelligence Programming [0]. It's not a direct route to the kind of programming most people do nowadays, but I hope to at least get a taste of what it was to be a researcher in classical AI. [0] https://github.com/norvig/paip-lisp https://github.com/norvig/paip-lisp
- nextos 8y agoNot only classical AI. If you bake in probability into logic-based Lisp & Prolog AI you end up in probabilistic programming. This is a very hot research topic. You can also then add deep-learning based samplers. It's all connected.
- agumonkey 8y agoas in this https://www.cs.cornell.edu/courses/cs4110/2016fa/lectures/lecture33.html https://www.cs.cornell.edu/courses/cs4110/2016fa/lectures/le...
- pvaldes 8y agoIt mades sbcl bearable at least. Not a minor point, so thanks stevelosh.
- deleted 8y ago[deleted]
- jordigh 8y agoIn Freenode's #mercurial, sjl said this about common lisp: <sjl_> CL code from the early 90's runs just fine on SBCL from a month ago <sjl_> But trying to run five-year-old python/ruby/scala makes me hate life. This echoes his earlier blog post, volatile software: http://stevelosh.com/blog/2012/04/volatile-software/ http://stevelosh.com/blog/2012/04/volatile-software/ I kind of have the feeling that fighting bitrot is sjl's main motivation for CL.
- stevelosh 8y agoI don't know that I'd go so far as to call it my main motivation, but it is absolutely one of the strongest motivators, yes.
- Jach 8y agoRunning decades-old code on modern implementations is also a characteristic shared by other languages (e.g. QBasic with FreeBASIC) so I'd hope it's not anyone's main motivation for Lisp. Still, it's a big plus. This is a great writeup to see how to start tackling the elephant that is CL...
- jordigh 8y agoElephant? Bit of a mixed metaphor, almost a malaphor, no? I'd say "tackle the behemoth" or "slay the dragon" instead. Elephants aren't usually tackled, they merely reside in rooms.
- tumba 8y ago> My advice is this: as you learn Common Lisp and look for > libraries, try to suppress the voice in the back of your > head that says “This project was last updated six years > ago? That’s probably abandoned and broken.” The stability > of Common Lisp means that sometimes libraries can just be > done, not abandoned, so don’t dismiss them out of hand. I have found this to be true in my own experience. The perception of stagnation is, however, a common initial objection to folks working in CL for the first time.
- mike_ivanov 8y agoMy personal problem with CL libraries is not that, but rather the lack of documentation. More often than not, there is no documentation at all, not even a readme file.. It feels like some library authors simply don't care. I'd say this attitude has a negative impact on how people perceive viability of those libraries -- and by extension, of the language.
- armitron 8y agoA lot of libraries that don't have separate documentation in the form of HTML/PDF/README.. are actually well-documented at source level in the form of docstrings. Since Common Lisp is an interactive programming language and is meant to be used interactively (think Smalltalk, not Python) it is common practice to (interactively) load a library in a Common Lisp image and explore it (interactively). One can see what symbols are exported from packages, what these symbols are used for and (interactively) retrieve their documentation. All of this takes place within the editing environment (ideally Emacs) in a rapid feedback loop (again think Smalltalk, not Python) that feels seamless and tremendously empowering.
- stevelosh 8y agoI agree with this -- it's a real problem. My only solution has been to try to be the change I want to see in the world and document all of my own libraries before I officially release them.
- earenndil 8y agoI do quite like common lisp, but: > In Common Lisp you can certainly choose to panic on or ignore errors, but there’s a better way to work. When an error is signaled in Common Lisp, it doesn’t unwind the stack. The Lisp process will pause execution at that point and open a window in your editor showing you the stack trace. Your warrior’s sword is hovering over the monster, waiting for you. At this point you can communicate with the running process at the REPL to see what’s going on. You can examine variables in the stack, or even run any arbitrary code you want. This doesn't seem like something that's particularly difficult to do with c/gdb.
- kilon 8y agoI have implemented live coding via DLLs for C , it’s not hard to do and can easily replace gdb. I don’t think that gdb offers live coding outside the box. Inspecting live state and to an extend REPL abilities do exist in GDB.
- JulianMorrison 8y agoLive editing the running code without a restart may be a mite harder in C.
- int_19h 8y agoIt's very hard (corner cases are nasty). That said, there are IDEs out there that support that sort of thing, e.g. https://docs.microsoft.com/en-us/visualstudio/debugger/edit-and-continue-visual-cpp https://docs.microsoft.com/en-us/visualstudio/debugger/edit-...
- lispm 8y ago> https://docs.microsoft.com/en-us/visualstudio/debugger/supported-code-changes-cpp?view=vs-2017 https://docs.microsoft.com/en-us/visualstudio/debugger/suppo... Looks like it has some severe limitations when it comes to interactive object-oriented programming: > Changes to a data type that affect the layout of an object, such as data members of a class. The Common Lisp Object System does not have such a limitation. The price to pay is some indirection. You don't even need to create new instances from your class. The existing instances will be updated for runtime changes: different inheritance, new slot, removed slot, different class, ...
- hirow 8y agoJust recently searched for an IMAP library but only found one for Allegro Common Lisp. The lack of libraries is one of my biggest concerns when it comes to using Lisp in production.
- vindarel 8y agoIt isn't that bad: - https://github.com/CodyReichert/awesome-cl https://github.com/CodyReichert/awesome-cl - http://quickdocs.org/ http://quickdocs.org/
- flavio81 8y agoThere are two more libs on Cliki: https://www.cliki.net/email https://www.cliki.net/email And note that CLiki does not cover all that it's out there.
- fiddlerwoaroof 8y agoI know from experience that clonsigna is broken :) I don’t think it would be difficult to fix, but, as is, it doesn’t work very well.
- vtail 8y agoI'm wondering what is people's opinion on modern Scheme dialects like Racket vs. Common Lisp? It seems to be pretty stable, with active development community, and comes with batteries installed.
- eadmund 8y agoWell, first off Racket is a different language from Scheme, although it's very similar. It's definitely very cool, and the folks involved have invested a tremendous amount of effort into it. At the end of the day, though, I prefer Lisp. I like that it's standarised; I like that so much code runs in just about every implementation; I like that — as someone noted elsethread — in Lisp it's not uncommon for libraries to be done. I like that Lisp is much more complete than Scheme. Standarised places are great. Standardised extensible types are wonderful. I don't like that so many in the Scheme community are so very opposed to adding to the language, no matter how painful the lack (witness the abject failure of R6RS). CLOS is amazingly good, better than any object system in any other language I've used. Scheme doesn't have a standard version. I think that multiple namespaces is a huge feature. A lot of Schemers disagree, but I don't see a good reason for functions, macros, classes, tags &c. to share a namespace, and it makes programs more obtuse. I don't care for Scheme's separate Boolean types, nor for the way it splits NIL, () & #f. They make code less concise, for no terribly good reason IMHO. Maybe that's a matter of taste, but I think it reflects the pragmatism of Lisp vice the idealism of Scheme. Lisp has standardised compiler macros. Lisp's normal macros are, I believe, more powerful than Scheme's (as I understand it, one can implement Scheme macros in Lisp but not Lisp macros in Scheme). Scheme's dynamic-wind is broken, while UNWIND-PROTECT isn't. Scheme's continuations in general are really awesome, but make it slightly too difficult to optimise code. I think it's great to have them available in an educational language, but not so great to have them in a general-purpose industrial language meant for real programs. Generally, when I come across some corner of the Lisp standard I don't understand, some years later I'll recognise how incredibly valuable it is to be able to have it, and how great it is that every implementation has it. I never come across any corner of the Scheme standards, because they have no corners. Whenever I write Scheme I'm not really writing Scheme — I'm really writing guile or whatever. Scheme's a wonderful language for teaching C.S. concepts like continuations & computer science in general — it's not IMHO a good language for industrial-strength software. Racket is a single implementation of what used to be a Scheme but has now grown to be something else entirely different. It's really cool — I just wish everyone involved had spent that time on SBCL & portable Common Lisp libraries instead. It's a free world, of course!
- typon 8y agoWould you recommend learning Common Lisp over Clojure?
- cultus 8y agoClojure is really your better bet. It is highly practical with a good community and excellent Java interop. You never have to worry about finding a good library. The syntax is also a bit more easily parsable than CL. If you don't touch the Java interop stuff, it's just as elegant as CL.
- typon 8y agoI've spent a few months learning Clojure - never gave CL a try. Here are a few thoughts on Clojure: 1. Excellent syntax and library support. It is my first Lisp, but I can't how I programmed without macros and persistent data structures. 2. I hate the stack traces. I've used both Clojure and Clojurescript (mainly cljs), and the stack traces for errors are nearly indecipherable. To be fair I am using React (not Reagent), but I don't find it too much better with other libraries. 3. I hate the build system. It is fractured and there are too many mediocre options. shadow-cljs is the best one I've used, and it works okay not great. I also hate that I can't distribute standalone binaries. I have used pkg, which distributes Node project as binaries, but the binaries are huge (something like 85MB+) 4. The core functional language is excellent, but protocols, types etc. seem much more ad-hoc and not well-designed. I'm used to object oriented (Python) and I find the lack of focus on an object-system a bit unsettling. I have no clue if Common Lisp fixes these issues or brings new ones.
- serpix 8y agoTo date I have not come up with a situation needing protocols or objects in Clojure that could not be just done with functional programming. The real killer superpowers come from extend-type and extend-protocol. You can modify existing java/clojure libraries functionality like magic. The functional equivalent is with-binding if I remember correctly. Some Clojure libraries use protocols heavily and IMHO not just necessary.
- 8y ago
- stewbrew 8y agoI just wish common lisp people would embrace static typing so that I could ask the reply/compiler: After all these changes, is the code still formally correct (as far as types were specified)? Typed racket/clojure show it's possible.
- foo101 8y ago> If you’re like me and already have Vim burned too deeply into your fingers to ever get it out, I’d recommend Vim with Vlime. Anyone has tried both Slimv and Vlime for Vim? What are the differences? Which one gives an experience closer to that of SLIME?
- Jach 8y agoI've been using slimv for hobby hacking for a while, but not professionally so you can take my commentary with a big grain of salt. You should try both, and if 'stevelosh likes vlime better you might start with that. I like slimv a lot better myself, and prior to that I made due with a gnu screen split-window terminal with a vim plugin that would send stuff from one screen panel to the other (used that for Python, Clojure, and Node sometimes too). I tried using vlime somewhat recently, but it just felt off, hard to express everything I didn't like but maybe the experience of having to launch your REPL separately was the beginning (slimv just finds your lisp on the path). You're encouraged to compile whole files at once rather than bit by bit (perhaps sensible for Real Work), the REPL buffer is read-only which is quite bizarre to me, and the default key bindings make less sense. Feature-wise it seemed comparable since they both use Swank. The tutorial at https://kovisoft.bitbucket.io/tutorial.html https://kovisoft.bitbucket.io/tutorial.html which follows a classic SLIME demo vid is nicer than the vim-tutor for vlime.
- stevelosh 8y ago> the REPL buffer is read-only which is quite bizarre to me The way I work around this is to run the SBCL process inside a Neovim terminal split (with rlwrap). That way I get a vanilla SBCL REPL plus the stability of Vlime.
- stevelosh 8y agoI've tried both. Slimv was always very buggy for me, especially the REPL buffer. I think this was because it was made long before any of the new Vim async stuff existed, and so had to do a lot of ugly hacks to get a reasonable REPL. Vlime was made after Neovim gave Vim a kick in the ass to add async, and it takes advantage of all of it. This lets its implementation be a lot cleaner and more stable, at least from what I've experienced. One thing I do that makes the REPL a lot nicer: I run the actual SBCL process inside a Neovim terminal split (with rlwrap). This gives me an actual REPL like you would expect, not just Vlime's "REPL" (which is essentially two separate buffers, one for input and one for output).
- rwallace 8y agoAn excellent guide, thanks! One suggestion: checked again just now and SBCL is still not production-ready on Windows (for the understandable reason of insufficient volunteers); perhaps the recommendation for that platform should be changed to CCL?
- flavio81 8y ago>One suggestion: checked again just now and SBCL is still not production-ready on Windows (for the understandable reason of insufficient volunteers); perhaps the recommendation for that platform should be changed to CCL? It only has a warning for threading code that has been left there for years. But I use it on windows with no problems. On the other hand Clozure CL is a very very good implementation with a loooooooooooooooooooooooooooooooooooooooooooooooooong history (emphasis added) being used in production stuff. But don't limit yourself to SBCL and CCL -- take a look also at ECL, ABCL, CLASP, etc.
- rwallace 8y agoThe Windows x86 version of SBCL crashes immediately on startup, so I figured the warning on the x64 version should be taken seriously, but if you are saying it is solid after all, that is good news. Going to give CCL a try.