and start debugging a misbehaving compiler macro used everywhere in a 1500-line multi-nested LOOP.
https://github.com/CodyReichert/awesome-cl
Thinking about recent feedback:
- https://blog.funcall.org//lisp%20psychoacoustics/2024/05/01/... (https://news.ycombinator.com/item?id=40233736) (2024) - https://news.ycombinator.com/item?id=33467269 (2022) "Common Lisp was a conscious decision because it allows a small team to be incredibly productive, plus the fact that it's a live image allows you to connect to it over the internet and poke and prod the current state, which has really allowed a much clearer understanding of the data." - https://lisp-journey.gitlab.io/blog/lisp-interview-kina/ (2020)
Often I just get "huh, that's neat, now let's get back to mining the coalface".
This particular post is better than most, and seems like genuine interest, and targeted at people already in the fold, which is fine. Though probably no one else is going see it and think "I gotta get me some of that."
The intentional advocacy posts, on the other hand... I usually don't see them appealing well to even the minority of programmers who are amenable to a low-employability platform. While they seemingly help to keep the platform low-employability, by making a weak pitch in the moment that someone was curious/bored enough to look at that link.
Claiming that “getting out of bed and programming in anything other than a lisp makes life less worth living” is at best as extremely immature and strange stance to take.
Edit: upon further reflection, this whole “lisp evangelism” is pretty tired. It’s not some magic bullet. Idgaf if paul goddamn graham knows how to write code in lisp. That means basically nothing, at all.
Sometimes people get offended when we give them a fully working awk/sed one-liner that does the job better but, uh, that's what we would have used ourselves!
(or "that's seriously computation heavy, use C/Rust/Julia/etc. because much though we love the perl5 VM for quick scripts and large-scale OO business logic apps this is not going to work nicely and trying to force perl to do it will be a rathole")
Though I do sort of miss my 'green threads via call/cc in guile sitting atop an ancient but functional perl event loop' system, it was ~20 years ago now and I'm not suggesting anybody else would ever want to use it, but in some ways it was still nicer than modern async/await style event loop driving nonetheless.
(yes, I'm an outlier and should not be counted)
There's quite the overlap between perlers and lispers because of (among other things) the shared love of 'building the language up towards the problem.'
People have been known to describe bits of my perl code as easiest read by treating it as lisp that incidentally uses a really weird sort of M-expressions and runs on the perl5 VM ;)
(Is something like Numba not a spiritual Lisp macro?)
Slow, bizarre in places, no live image though I can at least trivially replace function implementations and add methods to running code, binary building sucks, and there is of course a whole ass list of things that are uniquely awful (assume that the longest list you've seen from somebody who hates the language has 50% overlap with my personal list and that my list is probably longer) but ... it works. For me, at least.
I loved scheme; I keep picking at common lisp getting slowly better at thinking in terms of the capabilities of a system that's image based and deeply condition-system-ed, and I hope to get there eventually :D
A good one that I think is fairly typical of my annoyances - 'each' - the each keyword uses an iterator attached to the data structure it's iterating, so if you return or throw part way through doing so the iterator is left half way through and the next attempt at iteration will ... not do what you thought it would.
The reason for this is that 'each' was originally introduced back in the mists of time to allow iteration over a dictionary (hash) backed by a DBM file of some sort, and those files only -permitted- a single iterator at the same time.
Of course, people then started to use it for other things, but by that point making it behave a less surprising way for that would've broken existing code that used it for its original purpose (Larry and I chatted about this once and our conclusions mostly came down to 'alas').
Backwards compatibility is a hard master, and perl (and most cpan modules) work very hard not to break it, which leaves assorted things like that lying around.
My 'solution' is to accept this as fact and simply not use 'each', instead iterating over the keys and pulling the values out in the loop body, and honestly that's fine for me but it's moderately annoying having to keep telling newbies they need to pretend the keyword doesn't exist.
Things that freenode/libera #perl have found to be footguns often enough that we regularly teach people not to do that are collected in https://metacpan.org/pod/Perl::Critic::Community so you can find them with static analysis (and yes, of -course- each is on that list :) and might also be enlightening.
(I personally quite like using the behaviour covered by ConditionalImplicitReturn, but that one probably still belongs on the list because I suspect the vast majority of the time it gets used by accident and becomes a footgun with a delay fuse ... i.e. "if you know enough to use this safely, you should also know enough to turn that rule off" applies)
Part of the trouble I'd have producing a comprehensive such list is that so much of this knowledge has been baked into my brain/fingers long enough that there's not really any thought involved in avoiding triggering them anymore - my primary reason for mentioning it was "I am absolutely not blind to its faults, though every language has some somewhere" because I wanted to explain why I like perl overall without sounding like an Evangelism Task Force member.
But yeah, if you want to point me in a direction I'm still happy to dig through my brain and see if I can find you a representative example :)
The computer thinks imperatively. I prefer to be on common ground.