How the strengths of Lisp facilitate complex and flexible applications (2016) | Hacker News Reader

How the strengths of Lisp facilitate complex and flexible applications (2016)

pmc.ncbi.nlm.nih.gov

57 pointsMonkeyClub18 comments

If we are living in a simulation, you can be sure it is programmed in Lisp - that's why using it feels so magical, it's a glimpse behind the veil.

https://xkcd.com/224/

Some beg to differ: https://www.youtube.com/watch?v=u-7qFAuFGao

How many REPLs does God keep open at one time :-)

Lisp's advantages were negated decades ago. We have modern languages with modern type systems, modern tooling, and vastly more library support that make developing and maintaining complex applications way, way easier than Lisp. Try a large refactor that touches many aspects of a complex project (hundreds of thousands to millions of lines of code). It's a doddle in Java or TypeScript, especially with the refactoring tools in modern IDEs. The landscape has changed, massively, since Gat's 2000 paper comparing Lisp to Java. Strong static typing with modern ML-style type systems, alone, has been an unmitigated win in enabling the development of more complex applications with fewer bugs. Programmers are leaving a lot on the table by not adopting modern statically-typed languages, tools, and development environments.

I have been using Common Lisp professionally since 1982, and I agree with a lot of what you say.

I still enjoy CL for exploratory programming, but there are other languages I also reach for.

> I have been using Common Lisp professionally since 1982

I've been humoring thoughts of transitioning professionally from Java to Common Lisp (CL specifically, not a Lisp like, e.g. Clojure) for a couple of years now, but I've always hit that wall of few to almost no job postings for it in Europe.

I'm aware of the "awesome Lisp companies" list, and the occasional posting, but other than a few shops, it seems to me that Common Lisp is professionally not a very fertile field. That always brings me to a stop, when I try to invest some extra time to it, as it has to fight other priorities with a reduced perceived RoI.

Is that a correct perception in 2025, and CL is really not a viable option for a career, or am I missing something crucial?

I think it is challenging to find CL gigs now. My last gig before retiring a year ago was with a South Korean AI company that was all-in on Common Lisp, but after I retired someone there told me that they transitioned to Python. Still, if you love the language, just keep looking for CL jobs.

Horribly off topic, but: now that I am retired I thought that I would do all my experimental programming in Common Lisp and Racket, but in reality I am spending half my coding time using Python because of the ML, DL, and large language model tooling.

Thanks for at least confirming that I'm not horribly out of touch :)

Also I don't think your OT remark is OT at all - it sort of demonstrates which domains have actual traction nowadays and why.

>and I agree with a lot of what you say.

what, if anything, about what the GP says, do you not agree with? interested.

I see the value in languages like Haskell, even though I have only had one paying Haskell job, so I am a million miles away from being an expert at the language.

I liked the grandparent post’s opinion on Typescript: the type checking support can only help for very large projects.

Even with Python, I use Pendantic more often now, as well as type hints.

guessing you meant pydantic.

anyway, thanks.

R was heavily inspired by scheme, and I think that's a big part of why it's so popular in the scientific community (it's a great language for authoring DSLs). In fact, DSLs are so good in R that lots of midwit CS bros love to dunk on R the language, not realizing that what they're complaining about is in fact some library function. I like to tell people that R is "scheme on the streets, FORTRAN in the sheets". Just like Clojure deviated from I think R was very much developed as a Lisp designed to facilitate complex and flexible scientific applications (with an emphasis on statistical computing). I think you could develop a compelling analogy that Clojure:JVM::R:Numerics-oriented C/FORTRAN

From TFA, ...the creator of the R programming language, Ross Ihaka, who provided benchmarks demonstrating that Lisp’s optional type declaration and machine-code compiler allow for code that is 380 times faster than R and 150 times faster than Python

R is built on a Lisp-like run-time core, complete with symbols, and linked lists made of cons cells, etc.

I had no idea R was so much like Julia in that regard. Makes me wonder if the Julia devs were just like, "What if R, but more general?"

Nice high level overview wuth some case studies briefly described.

*with, typo.

Reply on news.ycombinator.com