[HN Gopher] State of the Common Lisp ecosystem, 2020
___________________________________________________________________
State of the Common Lisp ecosystem, 2020
Author : lelf
Score : 224 points
Date : 2021-02-08 15:10 UTC (7 hours ago)
(HTM) web link (lisp-journey.gitlab.io)
(TXT) w3m dump (lisp-journey.gitlab.io)
| yawn wrote:
| I like this as a general idea for users (and potential users) of
| programming languages. See also Sergey Tihon's tireless efforts
| with F# Weekly: https://sergeytihon.com/category/f-weekly/.
| wiz21c wrote:
| Interestingly, not much about ML. Surprinsing for lisp which, if
| I understand correctly, has roots in AI...
| pjmlp wrote:
| The AI of the first Winter had nothing to do with ML, rather
| expert systems and symbolic processing.
|
| Python is starting to look like the Lisp of the second Winter.
|
| https://norvig.com/python-lisp.html
| 7thaccount wrote:
| I don't think Python has the same issues. It was very popular
| as a scripting language long before it became good at
| numerical and data science work. It has always been free/open
| source and never required special hardware to run. Even if ML
| tanks, the impact to Python would be minimal.
| waynecochran wrote:
| Are we not heading for a 3rd AI Winter? The first being in
| the 1970's and the second in the 1980's and 1990's (which I
| experienced)?
| evgen wrote:
| I don't think there was a post-70s winter. There was just
| not enough 'there' to over-hype; it was toy problems that
| did not even try to masquerade as real solutions other than
| in sci-fi and popular culture. Luminaries in the field
| definitely made a name by pumping out speculative paper
| after speculative paper, but IMHO there was more of an
| ember waiting to spark than there was a fire consuming all
| of its fuel.
|
| By the late-80s and early-90s you have venture-backed
| companies, big institutional efforts, grifters who had
| honed their pitch in academic tenure-track positions prior
| to moving to richer waters, and the first real claims being
| made regarding just-around-the-corner deliverables that
| would change everything. Maybe I am jaded from experiencing
| that same winter, but from what I recall the prior decades
| were more consumed with people making broad claims to try
| to establish intellectual primacy more than making claims
| about what could be delivered.
| Jtsummers wrote:
| The term showed up in the 80s, but there was an earlier
| (70s) failure in AI. There were a lot of grand ideas and
| promises, people really did anticipate AI moving _much_
| faster in the 60s and early 70s than it did. Since a lot
| of ideas (both regarding AI and CS in general) were in
| their infancy, the limits of computers (fundamental
| limits) weren 't yet fully recognized, but also the
| hardware was itself creating limits (non-fundamental to
| the field) that weren't escaped until the 80s and 90s.
| See chess AIs of the 90s finally "solving" the problem,
| which would've been technically conceivable (how to do
| it) in the 70s but totally unrealizable (unless, maybe,
| you hooked every computer of the time together).
| vram22 wrote:
| By 1980's and 1990's, are you referring to the Japanese 5th
| Generation project?
| currymj wrote:
| doubt it's going to happen this time. the current crop of
| AI research is producing a lot of real results in all kinds
| of fields. voice transcription, recommender systems,
| translation, object detection -- all cases where neural
| networks have gone from research to widespread commercial
| deployment.
|
| there might be some kind of a contraction when people
| realize they're not going to get HAL-9000, or that you
| can't use deep learning to replace every white collar
| employee. but the results this time are much more "real".
|
| I don't think we will get another AI winter where the
| entire world completely gives up on the research area.
| KineticLensman wrote:
| > The AI of the first Winter had nothing to do with ML,
| rather expert systems and symbolic processing
|
| Between 1988 and 1992 I worked for a UK company participating
| in a multinational project to use Common Lisp to build an
| expert system building tool. After creating the thing, we
| worked with clients (internal and external) to try to solve
| real customer projects. Our conclusions matched others, and
| contributed to the AI winter:
|
| * the rule-based expert systems were extremely brittle in
| their reasoning
|
| * once you got beyond toy problems with small rule sets, you
| needed some programming skills in addition to the domain
| expertise that you were supposedly encoding
|
| * you sometimes spotted the actual algorithms that could be
| coded in a conventional language rather than rules +
| inference engine.
|
| We eventually abandoned the AI side and kept going with the
| underlying Lisp, and started to get real leverage in the
| company, rapidly becoming a prototyping / risk reduction
| group who delivered usable functionality.
|
| [Edit] We were using Lisp processors embedded in Macintosh
| hardware, with outstanding (for the time) IDEs and thanks to
| the Mac interface, we could create some really slick apps for
| the end users. One of our Lisp systems that got rave reviews
| internally was a drag-and-drop network modelling tool that
| replaced a frightening mass of Fortran and data entry
| spreadsheets. No AI/ML at all, but it really improved the
| throughput of our network modelling group. As we were a comms
| company, this got positive reaction from senior management,
| offsetting the non-return on investment in the rule system.
| jascii wrote:
| The focus of "AI" has shifted over time from symbolic
| processing (something lisps star at) to neural network machine
| learning, which requires more brute-force power.
| jefft255 wrote:
| I think the issue isn't "brute force power" (which python
| doesn't really have compared to CL if you look at the
| language itself), but rather the quality and completeness of
| numerical routines and GPU support. Matlab was very popular
| for early ML because it had the former.
| hajile wrote:
| Python is doing the actual lifting with C or Fortran, so
| I'd say brute force still applies quite a bit.
| bumbada wrote:
| I would say AI roots and research are lisp, as 99% of all early
| research work was done on lisp.
|
| Lisp was the language people like Richard Stallman or John
| McCarthy(the inventor of Lisp) used at MIT AI laboratory:
|
| https://en.wikipedia.org/wiki/MIT_Computer_Science_and_Artif...
|
| Everybody used Lisp there and young people that learned from
| the masters learned lisp too.
|
| But that was AI 1.0. Then came the AI winter and 2.0 spring
| with GPUs that were programmed in C dialects and gave
| incredible levels of raw power.
|
| So, as a high level access to low level C code, python was
| picked by most people.
| blackrock wrote:
| It would be great if Python had a PEP to automatically
| compile down to a binary executable file, and resolve all
| dependencies for it.
| Jach wrote:
| Nice write up. A small extra note for the community section, I've
| really appreciated Planet Lisp's (http://planet.lisp.org/) RSS
| feed. It aggregates a bunch of other feeds so you can more easily
| keep track of what's going on in the Lisp world.
| vasergen wrote:
| Out of topic, but as somebody who interested in lisp generally, I
| have a question, from which dialect would you suggest to start? I
| am a little bit lost. I am considering clojure, racket and common
| lisp. I am reading at the moment sicp book and do exercises in
| `racket sicp package` which is again another dialect. After that
| want to start with something modern. What was you way to lisp?
| filoeleven wrote:
| A note on Clojure: it's a lisp but the language has some
| important differences from (all?) other lisps that are inherent
| to its design. The two key changes are immutability by default
| and the sequence abstraction[1], with syntax differences being
| a close third. Sequences in particular mean that some pretty
| fundamental lisp functions don't operate the same way.
|
| There are two ways to look at this. One is that they encourage
| better coding practices, the other is that they are
| restrictions that diminish the power of the language and make
| you jump through unnecessary hoops to get stuff done.
| Basically, "guard rails" vs "training wheels."
|
| I can't say much more since Clojure is the only lisp I have
| played with (and I don't see this changing, I quite like the
| language design). Code written in Clojure is not trivially
| portable to other lisps, and vice versa. I think there are
| differences in what you can do with macros too.
|
| No value judgment here, I just think it's important to know
| that these non-trivial differences exist when choosing which
| language to explore.
|
| [1] https://clojure.org/reference/sequences
| samvher wrote:
| I started with SICP to understand Lisp conceptually (it also
| taught me a lot about abstraction). Then I worked through
| Practical Common Lisp to learn the ecosystem a bit better and
| programmed some tools for my own tasks. Finally I worked
| through "Write yourself a Scheme in Haskell" which deepened my
| understanding and actually ended up with me spending more time
| with Haskell than with Lisp (it was a gateway drug to more
| structured functional programming). Overall this sequence was a
| very satisfying experience and I now find myself spending most
| of my time with Erlang which feels a bit like middle ground.
| Jtsummers wrote:
| Clojure - Learn this if you want a job programming in a Lisp
| family language. It's the most reliable one for achieving that
| goal. Good library support due to being hosted on top of other
| languages (like Java). It's an opinionated language, generally
| pushing the functional style and immutability.
|
| Scheme - Great amount of good learning materials. Smaller
| language, gets to the core of writing in both a lisp and
| functional style quickly. Pure Scheme code should trivially
| work across implementations. If you ever deal with external
| libraries your choice of implementation becomes more critical.
|
| Racket - You're using this already. Also a good language, and
| you can reuse the Scheme resources on top of it because it has
| language modes that are compatible with Scheme. Like with
| Clojure, you're dealing with a singular implementation so at
| least that choice is gone for you. Libraries should "just
| work".
|
| Common Lisp - Like with Scheme, implementation choice does
| matter somewhat. Multiparadigm, so you're a bit freer to choose
| how to implement your program (you can adopt a more procedural,
| functional, or OO style to suit your needs or wants at the
| moment). It's less opinionated than Scheme and Clojure. Some
| good learning resources out there, some of the Scheme materials
| translate well (in that they work) but don't teach good CL
| style.
|
| To answer your specific question:
|
| I first learned Scheme helping college mates who were a year or
| two behind me as GT switched to Scheme as its first CS course
| language after I took it. I really learned the lisp family with
| Common Lisp in grad school from an AI course that was using
| Norvig's _Paradigms of AI Programming_ , and I kept using it as
| a hobby language ever since.
| iainctduncan wrote:
| I think you should also add to Scheme: great for embedding a
| lisp DSL in another app. Scheme's minimalism means there are
| a number of excellent options for working this way. I use S7
| myself.
| tines wrote:
| To me, the entire point of Lisp, the thing that sets it apart
| from other languages, is unhygeinic macros. Since that is my
| view, I can only recommend Common Lisp. CL is the opposite of
| modern, but just because something is modern doesn't make it
| good, nor does old make bad.
| bjoli wrote:
| As someone who has written a lot of CL and now deals mostly
| in scheme, why is an unhygienic macro system important? I
| don't think it matters much, and frankly I think something
| like vanilla syntax-case isn't hygienic enough. Either I
| don't want to care about accidentally capturing identifiers
| (and be very explicit when I do want it - Day like in
| srgi-72), or I want to have a system where I deal with
| explicitly (defmacro)
|
| Which I am using matters very little.
| Jtsummers wrote:
| As an attempt at an answer: Unhygienic macros offer you
| more "power". With care, or another macro, you can express
| exactly the things you want with hygienic macros in a
| system like CL which lacks them, but the reverse isn't
| true. I cannot think of anything off the top of my head
| which would be particularly useful with unhygienic macros,
| but there probably is a use-case. My best guess (and just a
| guess) might be the SERIES and SCREAMER packages which
| redefine _defun_ , but I could see it going both ways. A
| hygienic macro within the SERIES package would know the
| local definition and use it, but one from without would use
| _cl:defun_.
|
| With either hygienic or unhygienic macros this can create
| problems as in either case you may think you're using a
| particular _defun_ when you 're really using the other.
|
| NB: My CL macros are written carefully so they'd be roughly
| equivalent to the hygienic macros of Scheme, but with more
| boilerplate. At least when it comes to most variables, but
| I don't take care to ensure the functions used in my macros
| are not replaced in the local context where they're used.
| bjoli wrote:
| I don't believe anything that can be written with
| unhygienic macros can't be written in a hygienic macro
| system. Macros written using implicit renaming is written
| just like CL macros, and with enough libraries you can do
| something similar with syntax-case.
|
| Heck, implementing an unhygienic defmacro over a regular
| lambda is something like 7 lines of syntax-case. In guile
| you could even use lambda* to get optional and keyword
| arguments.
| Jtsummers wrote:
| So, again, I don't think I know for certain why I'd want
| to do this, but here's an example of different behavior
| with the two: (defmacro my-not (x) `(not
| ,x)) (flet ((not (x) x)) (my-not 't))
|
| In a hygienic macro system, that local definition of
| _not_ will have zero impact on the execution. In an
| unhygienic macro system, that local definition is used
| instead of what the macro writer probably intended. That
| 's a stupid, trivial example that would hopefully never
| be written. My best guess for wanting something like
| this, per my previous comment, would be a system like
| SCREAMER or SERIES which could make use of this local
| redefinition to produce a different-than-standard
| behavior.
|
| How would you write a hygienic macro which would make use
| of the local redefinition of _not_ without also having to
| pass the redefinition to the macro?
| fiddlerwoaroof wrote:
| This is right, but shadowing symbols in the CL namespace
| like this is usually not allowed: the compiler is free to
| optimize a lot of these things by inlining definitions
| and such, so this may not do what you think (unless you
| shadow CL:NOT)
| bjoli wrote:
| I would use syntax case and introduce unhygienic
| bindings. That is the deal with all low-level hygienic
| macro systems: hygiene by default. Break hygiene
| explicitly.
|
| In syntax-case that would be (datum->syntax syntax-
| object-where-i-want-to-introduce-binding 'not)
| varjag wrote:
| In a lisp-1 like Scheme it's a lot easier to shoot yourself
| in the foot with unhygienic macros.
| bjoli wrote:
| I don't think that matters. Either you write a macro that
| is correct that won't break because of unwanted
| intersection with the place of expansion, or your macro
| is wrong.
|
| Edit: barring code-walking macro of course. Once you
| start using those, the bets are off.
|
| Edit2: of course, I don't think overwriting core forms
| count either. That is poor bedside manners :)
| varjag wrote:
| Rather than rehash the ancient argument once again, I
| defer to this post:
|
| https://www.xach.com/naggum/articles/3225161536947499@nag
| gum...
|
| (KMP was on both Common Lisp and Scheme standard
| committees; Erik Naggum was an eloquent, if
| controversial, Lisp expert)
| tines wrote:
| Correct me if I'm wrong, but Lisp-2 vs. Lisp-1 has
| nothing to do with hygiene, it just splits Scheme's
| single problem (lexically binding values in macros) into
| two problems (lexically binding values in macros, and
| lexically binding functions in macros).
|
| The real problem, which Naggum includes, is the lack of
| GENSYM (if scheme indeed lacks it), and lack of first
| class symbols, as he mentioned.
| ska wrote:
| It's somewhat orthogonal, yes, but a lisp-1 just has more
| ways to run into the name collision.
| tines wrote:
| The unhygeinic part isn't as important as the fact that
| CL's macros (and other macro systems) are not simple
| pattern matching and substitution. But the lack of hygiene
| completes the circle for the concept that the program is
| simply a data structure, and macros are just imperative
| functions from syntax to syntax, and they can do anything
| that a normal function can do, like make HTTP requests.
|
| The destruction of the distinction between your code and
| the compiler, and the recursive relationship between the
| reader (and CL has reader macros, another dimension),
| macroexpander, and evaluator, is what is so mind-opening
| about lisp to me, and CL embodies that trifecta with the
| most ideological purity (imo).
| [deleted]
| iainctduncan wrote:
| There are various hybrid schemes that support CL style
| macros. I'm using S7 myself, because embedding in a C host is
| what I'm after. I love it, it has support for CL macros with
| gensym and first class environments, and embeds easily in C.
| tines wrote:
| What's S7? I've never heare of it.
| reikonomusha wrote:
| Common Lisp with Emacs and SLIME if you want to do "ordinary
| programming" and want to really "feel" what Lisp is all about.
| mac01021 wrote:
| What kind of applications do you want to build? What non-lisp
| languages do you usually work with?
|
| I think you will find that Clojure has the largest community
| and the widest use for commercial applications but, depending
| on your specific interests, either racket or common lisp could
| be a better fit.
|
| In summary, I think we need more information about your goals.
| vasergen wrote:
| Thanks, good points. I am working primarily with nodejs /
| typescript. So, yeah lisp is a totally different paradigm for
| me. In terms what want to build, backed and cli tools would
| be a good start for me.
| mac01021 wrote:
| I'm going to say Clojure is probably what you want. Via
| clojurescript, it has very good interoperability with the
| tools you're already using and it's possible that you might
| even choose to use it on the front end in the browser.
| That, coupled with the size of the community suggest to me
| that it is the winner here.
|
| For the (browser) front-end, there are lots of neat
| idiomatic-clojure libraries like https://reagent-
| project.github.io/
|
| For command-line scripting, your program will ultimately
| mostly access the filesystem or other OS functionality via
| interop with the host platform (either Java or Node).
| pid_0 wrote:
| I just don't get the appeal of Lisps. They look so ugly and the
| syntax seems crazy
|
| ((((((((((((((((( by the way
| noidesto wrote:
| Look crazy to fresh eyes. I've found it to be a non-issue the
| more I write lisp code. With structural editors like parinfer,
| paredit, smartparens, etc. it becomes a whole lot better.
| iainctduncan wrote:
| tastes differ. I'm a lot more averse to: end
| end end
|
| end
|
| or in JS: }); }); });
|
| });
| kazinator wrote:
| That much stacking of opening parentheses is never seen, only
| ))))))).
|
| Typing )))... is easy; just hold down the ) key to repeat, and
| watch the cursor jump back and forth due to parenthesis-
| matching. When it flicks back to the correct target, release,
| and backspace over any overshot parens.
| lukego wrote:
| I really appreciate this effort. I'm coming back to Common Lisp
| after a long absence and I'm very interested in understanding
| what the most relevant projects are these days.
|
| Can be hard with Lisp due to the long history and strong
| backwards compatibility. I've started using Screamer for the
| first time today and that was written around 30 years ago...
| waynecochran wrote:
| Some of the happiest days of my programming life was during a
| brief stint in grad school doing AI programming in Common Lisp
| (circa 1992). The purity of functional programming and the rapid
| implementation of algorithm PoC's was pure joy. The pragmatics of
| life have kept me from using CL since them -- I wish this effort
| the best success.
| galaxyLogic wrote:
| A question: How does CLOS rate in terms of "functional purity".
| Or does it matter? The biggest selling point of Haskellers seems
| to be that Haskell is a "pure" functional language. Are there
| practical problems caused by mutable data in CLOS?
| kras143 wrote:
| The best progamming book I have read so far is "On Lisp". Reading
| that book and coding Lisp for sometime was the best time I spent
| programming. Unfortunately, the whole thing was purely academic.
|
| Thanks for the effort and the information you put together.
| retzkek wrote:
| Note that PG has made "On Lisp" available for free:
| http://www.paulgraham.com/onlisptext.html
| pronoiac wrote:
| It looks like someone else found and re-added the diagrams:
| http://www.lurklurk.org/onlisp/onlisp.html
| reikonomusha wrote:
| I think this article (of sorts) is definitely helpful for
| onlookers to Common Lisp, but doesn't provide the full "story" or
| "feel" of Common Lisp, and I want to offer to HN my own
| perspective.
|
| Disclaimer #1: I've been working professionally as a Common Lisp
| programmer---not as a contractor!---for the past decade. I have a
| vested interest in the language and hiring for it.
|
| Disclaimer #2: I am going to ignore commercial implementations of
| Lisp here, which provide very useful and advanced features, like
| GUI development, a user-friendly IDE, paid support, etc. [1,2]
|
| So let's get started. Common Lisp's best feature is that it
| allows you to be insanely productive at the "raw programmer"
| level. You can write, edit, and debug code very quickly and
| incrementally, and end up with safe & performant code.
|
| There's a price to pay: currently the best-in-class experience is
| still Emacs and SLIME (which come nicely packaged here [3]). As
| an Emacs fan, that's the best news, but to my fellow
| PyCharm/VSCode/vim users, it's terrible and alienating news. My
| colleagues who aren't Emacs users managed to learn just enough
| Emacs to be productive in a week, but they still frequently fired
| up their editor of choice in times of need.
|
| It really is worth underscoring that the Emacs+SLIME experience
| truly fits Common Lisp development like a glove, and the
| experience, in my opinion, is better than almost every mainstream
| editor environment out there.
|
| Common Lisp's worst feature is that it feels like just about
| everything imaginable has a catch. I don't mean "there's no free
| lunch", I mean that things just plainly don't feel _cohesive_ or
| "100%" most of the time. To name a few examples:
|
| 1. GUIs: If you want to make a traditional, native GUI using open
| source solutions, you're stuck with really goofy libraries that
| are non-obvious to get working. As the article points out, you
| have options. Lisp actually has a renowned framework called CLIM,
| but I consider the open-source implementation McCLIM [4]
| currently only principally useful to hobbyists and hackers.
|
| 2. Deploying applications: Almost every implementation of Lisp
| has some way to create an executable. But _very important_
| aspects that real people care about in production are missing,
| inconsistent, or poorly documented. For example, almost no open
| source implementations of Lisp have first-class support for
| signing binaries on MacOS. Almost no open source implementations
| have a "tree shaker" to remove unnecessary cruft from the
| executable. Almost no open source implementations make building a
| shared library practical.
|
| 3. Libraries: Many libraries don't do even usual things people
| might want to do. The linear algebra library MAGICL [8], for
| example, doesn't at the time of writing have a way to solve the
| matrix equation Ax=B. This isn't due to laziness of the authors
| or lack of foresight, but rather that it's a library that's just
| not used by enough people to see regular, high-quality
| contributions as an open-source project. I'm sure MAGICL solves
| problems for the authors, but the authors haven't taken it upon
| themselves to make a general, useful, and quasi-complete library
| for matrix programming in Lisp.
|
| These examples are just examples, maybe not even the top
| examples.
|
| There are many things I wish for Common Lisp, but there are two I
| think I wish most.
|
| First, I wish Common Lisp implementations put in work so that
| they could play nice with other programming languages. Google
| [11] recently came out with support for protobufs in Lisp, which
| is nice, but I feel something deeper is needed. I think Common
| Lisp implementations supporting building C ABI-compatible shared
| libraries would be an insanely big step forward; it'd mean that
| Lisp could feasibly used by every language out there. Right now,
| the closest we've got is Embeddable Common Lisp, an
| implementation of Lisp which makes embedding Lisp within C
| relatively painless, but as usual, it has many catches [12].
|
| The way I've coped is to produce stand-alone command-line
| applications, or to build servers with HTTP APIs. But it feels
| icky, especially if you're working with Python programmers who
| want to `import` stuff and not run servers just to get some code
| to work.
|
| Second, another thing that I constantly hope for in the Lisp
| world is for more "hyper productive" programmers to join it, or
| programmers whose livelihood depends on it. Of course, since Lisp
| is used by hobbyists, you see tons of hobbyist code. To be sure,
| a lot of this hobbyist code is perfectly fine. Usually it works,
| but it's just a tad incomplete. However, in my opinion, the worst
| thing about hobbyist code is that _it usually doesn 't do
| something useful_.
|
| What does "useful" even mean? I won't claim to be able to define
| this term in a one-size-fits-all fashion, but "useful" to me is
| about getting practical computing work done. The further away
| from being concrete the library is, typically the less useful it
| is. For example, a typical Lisp programmer will have a penchant
| for writing a domain-specific language for parsing binary files
| (cool!), will open-source that code (cool!), but then nobody---
| including the author of said library---will actually use it to,
| say, write a parser for GIFs [5]. When somebody _does_ come along
| to write a GIF parser, they 're likely not going to use this
| general binary parsing framework, but hand-roll their own thing.
|
| In Lisp, it seems popular to solve meta-problems instead of
| problems, which is partly due to the fact that Lisp lets you
| think about problems at very high levels of abstraction using its
| advanced object system, the meta-object protocol, and macros.
|
| (One of my biggest "pet peeve" projects in Lisp, second only to
| "utility libraries", are documentation generator libraries. As
| soon as somebody figures out that documentation strings can
| actually be programmatically queried in Lisp, they invariably
| write a baroque "generator" that spits out HTML. I've never, not
| a single time, ever, used a documentation generator for doing
| real, paid work. I think one Lisp programmer I know uses it
| nicely is Nicolas Hafner, aka Shinmera, who uses a documentation
| generator simply to augment his long-form documentation writing.
| Staple [9] is one example library of his, where you can see some
| generated documentation at the bottom.)
|
| "Useful" also has to do with how a library is consumed. In the
| Common Lisp, a library like this [6] is typical. It's a bare page
| (be it on GitHub or otherwise) that provides no examples, no
| indication of dependencies, etc. Not all libraries are like this,
| but you run into it frequently enough.
|
| The Common Lisp ecosystem lacks a certain "go-getter" philosophy,
| needed to forge through "boring" work, that some other language
| ecosystems seem to have. To cherry pick one example, though I
| don't use it, Zig [7] comes out with interesting stuff all the
| time that's genuinely useful. Andrew Kelley, its main developer,
| is putting tons of hours into getting details around deployment
| right (e.g., cross-compilation). Little about Common Lisp
| prevents a motivated person from making equally productive-
| enhancing strides with the language, but I find that either (a)
| the interest isn't there or (b) the interest is there but the
| interest is for developing weird, esoteric stuff in Lisp.
|
| (My favorite example of a "productive stride" that happened in
| Lisp is the following. For context, people talk about all the
| time how difficult it would be to port a Lisp compiler to a new
| architecture. I myself have clamored for documentation on how to
| do it with SBCL. But, out of nowhere, some grad student named
| Charles Zhang came out with a port of SBCL to RISC-V. Not only
| did he port it, he's maintained it with 100s of new commits,
| making it more performant and less buggy [10].)
|
| Common Lisp is an amazing language purely from a practical point-
| of-view. As I said, to me, it's bar-none the best and most
| productive language to use if you want to "sit down and write
| code". The implementations of Lisp, like SBCL, are marvels. Lisp
| code, once you write it, will work forever (seriously, decades).
| The #lisp channel on Freenode is nice and helpful, and there are
| so many amazing people in the community. In Lisp, it's seamless
| to inspect assembly code and work with the world's most high-
| level, meta-object systems all at the same time. But the
| ecosystem mouthfeel is still off, and Common Lisp would greatly
| benefit from programmers obsessed with making the language more
| useful to themselves _and others_ today.
|
| [1]: LispWorks: http://www.lispworks.com/
|
| [2]: Allegro CL: https://franz.com/products/allegro-common-lisp/
|
| [3]: Portacle: https://portacle.github.io/
|
| [4]: McCLIM: https://common-lisp.net/project/mcclim/
|
| [5]: There is a GIF parser though called SKIPPY!
| https://www.xach.com/lisp/skippy/
|
| [6]: MIDI: http://www.doc.gold.ac.uk/isms/lisp/midi/
|
| [7]: Zig: https://ziglang.org/
|
| [8]: MAGICL: https://github.com/rigetti/magicl
|
| [9]: Staple: https://shinmera.github.io/staple/
|
| [10]: Charles Zhang's SBCL commits
| https://github.com/sbcl/sbcl/commits?author=karlosz
|
| [11]: CL-PROTOBUFS: https://github.com/qitab/cl-protobufs
|
| [12]: Poorly documented, performance isn't very good, it's
| maintained by essentially one person, the rituals needed to use
| ECL-built libraries are more extensive than necessary, build
| times are insanely slow, ...
| Blackthorn wrote:
| > Common Lisp's worst feature is that it feels like just about
| everything imaginable has a catch.
|
| You've put into words something I've struggled with saying for
| a while, and the exact reason I could never really enjoy
| working with Common Lisp.
|
| The example I always return to is the lack of pervasive use of
| CLOS throughout the standard. Something like generic-cl[0]
| feels like it should be a baseline part of the language. As it
| is, it's a great library. But people are hesitant to even use
| it, because the result of making everything generic is a loss
| in performance!
|
| Of course, [0] talks about optimizations they've done. I don't
| know how it compares to using the methods in the standard as
| opposed to the lib. Regardless, these libs only help when
| writing code, not reading it. Though don't get me wrong, that's
| a big deal! It's very helpful! But you wish everyone would play
| by those rules.
|
| [0] https://github.com/alex-gutev/generic-cl
| vindarel wrote:
| If you want to regain performance, add-in type declarations,
| cl-generic will inline its functions:
| https://github.com/alex-gutev/generic-cl/#optimization
| dTal wrote:
| Perhaps one could write a type-inference macro. That would
| leave you with something like Julia, broadly speaking.
| Jtsummers wrote:
| This seems like a consequence of the language never getting
| another standard. If it did, and given the way Common Lisp
| systems work, I think there could've been something like
| _cl2_ and _cl2-user_ packages which could 've pushed more
| towards that generic style that CLOS promotes, and maybe
| eliminated some of the elements that were redundant or didn't
| _quite_ fit with everything else (is it `(function sequence
| index)` or `(function index sequence)`?). Those conflicts
| make sense given the history of the language (it was created
| to help connect several branches of the lisp family). And the
| older standard would 've been easily preserved in the _cl_
| and _cl-user_ packages.
|
| But the language is essentially frozen in the existing
| standard, and can only be extended by community consensus
| right now.
| aaron_m04 wrote:
| Thanks for the amazing write up!
|
| > There's a price to pay: currently the best-in-class
| experience is still Emacs and SLIME
|
| Does viper-mode work well with this setup for vim users?
| reikonomusha wrote:
| I hear yes but I don't have experience. The particular
| editing commands aren't what make SLIME nice, it's the
| interop. Viper should be fine.
| vindarel wrote:
| > Google [11] recently came out with support for protobufs
|
| Not only:
|
| > Doug Katzman talked about his work at Google getting SBCL to
| work with Unix better. For those of you who don't know, he's
| done a lot of work on SBCL over the past couple of years, not
| only adding a lot of new features to the GC and making it play
| better with applications which have alien parts to them, but
| also has done a tremendous amount of cleanup on the internals
| and has helped SBCL become even more Sanely Bootstrappable.
| That's a topic for another time, and I hope Doug or Christophe
| will have the time to write up about the recent improvements to
| the process, since it really is quite interesting.
|
| > Anyway, what Doug talked about was his work on making SBCL
| more amenable to external debugging tools, such as gdb and
| external profilers. It seems like they interface with aliens a
| lot from Lisp at Google, so it's nice to have backtraces from
| alien tools understand Lisp. It turns out a lot of prerequisite
| work was needed to make SBCL play nice like this, including
| implementing a non-moving GC runtime, so that Lisp objects and
| especially Lisp code (which are normally dynamic space objects
| and move around just like everything else) can't evade the
| aliens and will always have known locations.
|
| https://mstmetent.blogspot.com/2020/01/sbcl20-in-vienna-last...
|
| also, ASDF's main author spent his career at Google.
|
| > the best-in-class experience is still Emacs and SLIME
|
| Really I want to mention again that Atom's SLIMA is getting
| very good. The Sublime plugin and a VSCode one are coming
| close.
| reikonomusha wrote:
| dougk is one of the few people currently and immediately
| capable of such "long strides" I spoke of. He is continually
| improving SBCL in remarkable ways, especially under-the-hood
| work that just makes all Lisp applications better without
| additional work on the programmers' parts.
|
| I attended the Vienna conference where he discussed such
| matters, and he has great ideas, but many of his play-nice-
| with-UNIX tools are still very bleeding edge and require you
| to be SBCL-developer-level in-the-know to use them.
|
| I hope later this year that I'll be able to open up a full-
| time role for SBCL development as a part of my own job, in a
| similar way that Google employs dougk to work on SBCL. The
| only trouble will be finding a qualified applicant who can do
| the full-time work...
| abhinav22 wrote:
| Thank you very much for this detailed and insightful post. Much
| appreciated
| [deleted]
| kazinator wrote:
| Counterpoint: Lisps are productive even if you always save all
| your work into files and rebuild an image, as if you were
| working in C++.
|
| The result of working in Lisp is nice code, and that code
| continues to be nice as the months and years go by, long after
| the interactive session in which that code had been developed
| has been forgotten.
| slim wrote:
| what you are saying is "use lisp if you don't want any
| dependency". it's a practical use case
| reikonomusha wrote:
| I'm not saying that. I use Lisp and my Lisp programs have
| dependencies and my other programs depend on Lisp. I'm just
| saying that (1) Lisp can still stand to integrate better in
| today's OS/language scene, and (2) Lisp could benefit from
| people writing additional high quality libraries. (Lisp has
| _many_ high quality libraries, but it needs more.)
| lars-b2018 wrote:
| Thank you for this write up. Mostly agree - been using Common
| Lisp seriously (almost every day as part of my work). At our
| company almost all NEW back end work is done in Common Lisp as
| the first choice.
|
| FWIW, in my computing career there have been two crucial pivot
| points. Exposure to and programming and using Unix (SunOS/HP-UX
| and later Linux) and its powerful mode of working was the first
| epiphany. And later Common Lisp, and the degree of freedom it
| enables in expression of code and ideas, as well as its speed
| and interactivity model: REPL/SLY, EMACS etc. I have become a
| much better programmer because of my exposure to this mode of
| working.
|
| When I was first starting though, my frustration with the
| language was large, and it was compounded with learning Emacs
| (which I love and curse at on a daily basis). Libraries seemed
| poorly and very inadequately documented for someone new to the
| language, especially compared to Python for example. But the
| newish culture of hosting open source projects in Github is
| improving and READMEs/project descriptions are getting better.
| And, doc strings are in the code themselves, mostly...
|
| Common Lisp gets criticized for not changing. Sometimes it can
| be a bit verbose (setf (gethash mykey my-hash-table) my-value).
| A lot of programmers will instantly gravitate to "that's a lot
| of words to set a value in a hash table". But it really isn't
| the problem it turns out to be in real life because you learn
| to read it pretty damn quick, and you save key strokes
| elsewhere (for example using loop or CLOS). So it balances out.
| However, I have come to learn that having a rock underneath
| that has no problem running years old code is a HUGE benefit.
| Things generally continue to work with the updated compilers
| and that reduces the cost to maintain the code base. I trust
| the language to stay solid underneath. You _can_ extend it, but
| you generally don 't need to use reader macros and other
| features to solve most problems. So while the world is changing
| around you, you aren't updating your python2 to python3.
| Instead you can stay focused on app level changes.
| taeric wrote:
| Setf is a fun example of an amazing freedom in naming. You
| name how to address something, and setf is how you set things
| at that address. No longer do you have to have two names for
| one address, depending on if you are getting it or setting
| it.
|
| And completely agreed on stability. I love that all of the
| code samples from all of my lisp books still work. Seems that
| number approaches zero for all the other languages. :(
| setpatchaddress wrote:
| Thank you for this overview -- the article itself doesn't seem
| super useful unless you already have this context.
|
| I glanced at CLIM, and it's very much still traditional
| verbose, imperative GUI code. Someone should really take a look
| at doing a Lisp version of the SwiftUI concept. It seems to be
| made for s-expressions.
| kazinator wrote:
| Note that declarative syntax for specifying GUI properties is
| actually old hat, too. (Even if we ignore things like HTML
| and CSS).
|
| I mean, for instance, oh, Windows resource files.
|
| Glancing through CLIM, I also don't see anything like that
| sort of separation between GUI logic and form.
___________________________________________________________________
(page generated 2021-02-08 23:00 UTC)