I was hoping it would address Lisp.

Lisp is fun. The interactivity and instant turnaround of a Lisp REPL is still rarely matched in other languages. Common Lisp also solved a significant issue other languages didn't address well until much later: the ability to write high-level code that was fast on cheap hardware around the turn of the millennium.

Lisp didn't get popular around the turn of the millennium. Success stories like Naughty Dog, ITA, and Viaweb were rare, and the dominant languages seemed to be Java and various scripting languages starting with the letter P.

▲

jottinger an hour ago | parent | next [-]

Hah! SO MANY LANGUAGES got skipped, even from my own CV. I wanted to address Louis/II, for goodness' sake, but it's a CODASYL tool, and not a lot of people remember CODASYL from experience. (Nor should they: I liked it, but... nah, RDMS won for good reasons.)

Lisp is certainly fun, and it lives today and is influential today in multiple environments; I have a Clojure app I work on for my own amusement. And it does have commercial appeal, but it's limited; the three axis thing applies.

▲

Geof25 an hour ago | parent | prev | next [-]

I often hear about lisp but never actually figured out what tooling you need Is it interpreted or compiled language? Why should I use it instead of any other languages?

▲

stackghost 41 minutes ago | parent [-]

"Lisp" refers to several different languages in the same family, which contributes to the confusion.

Perhaps the default choice is Common Lisp which itself is specified in an ANSI standard and has several competing implementations. Some are compiled, some are interpreted.

Arguably the best is SBCL, which has a mature compiler and garbage collection. If you lean on implementation-specific features you can produce extremely fast code that approaches the performance of C in some benchmarks, but idiomatic and portable lisp is slower in practice.

>Why should I use it instead of any other languages?

The killer feature used to be the REPL. You can write the application function by function, and test the functions, data structures, or classes you write in the REPL as you're actively building the app.

Nowadays with LLMs writing all the code, I honestly don't see much reason to reach for lisp. Agents don't require a REPL, and other languages have vastly superior library support.

▲

guenthert 4 minutes ago | parent | next [-]

> The killer feature used to be the REPL.

The killer (hah!) feature is arguably its homoiconicity, allowing to modify the language easily within itself ("macros").

> Nowadays with LLMs writing all the code

Oh, you came all the way from the future and that's what you bring us?

▲

red_admiral 30 minutes ago | parent | prev [-]

> You can write the application function by function ...

and then use JUnit or TestNG in Java, or similar features in other languages. Which you can automatically run, including showing code coverage, both with a button in your IDE and as part of the CI/CD process when you commit.

	▲	Zak 19 minutes ago \| parent [-]
		Unit testing doesn't provide the level of interactivity a REPL does. A REPL lets you see the output of parts of an unfinished function based on the running program's state. If you've already thought out the whole program before you start writing it, that may not be as valuable. In my experience, software often isn't that way and the ease of exploration a REPL and long-running process provide are unmatched.

▲

stackghost an hour ago | parent | prev [-]

I really enjoy writing lisp but the ecosystem of libraries is a barren wasteland.

Try to find a TLS library for Common Lisp that doesn't rely on openssl, for example. Last time I looked the most mature library was marked 'experimental'.