That's a Catch-22, of course. How will you know if it's a good fit for you unless you learn it?
So that reduces the decision to: if you are curious whether Lisp is a good fit for you, learn enough of it to find out. If you're not curious about that, don't bother.
But you might want a preview of what things make it a good fit for some people. Lisp in general, and Common Lisp in particular, is a good fit for me because its default mode of operation is to start the Lisp running and teach it by interacting with it expression-by-expression how to be the program I want to build. Common Lisp is consciously designed to work this way, and provides a host of well-designed conveniences for it. It turns out that working that way makes me happier and more productive than working any other way, so it's my favorite programming language.
Not very many other programming languages work that way, but to be fair, some do. Examples of some that do are Smalltalk, FORTH, and Factor.
Some languages and implementations provide more support than others for that style of work. The most comprehensive support for it is to be found in Common Lisp and Smalltalk implementations.
If that sounds interesting, then it's probably worth your time to learn Lisp (or one of the other languages I mentioned). If not, then I wouldn't worry about it.
The simplest app I have in prod reads data from an existing DB, formats it and sends it to a FTP. No UI, it's a CLI. Runs daily with cron. Was easy to build, to deploy (standalone binary), to maintain. Build and forget.
Same goes for computer languages. I use LISP when I have computer science-y things I want to explore. For example, I was working on a path finding algorithm for fun years ago and I went to LISP because it is much more natural at conceptual programming. But I wouldn't use LISP to create a GUI, even though it can, nor would I try to write performant 3D graphics. But I would use it to craft a game engine (I wrote a frame language in the early 2000's as part of a game engine that I never finished because once i got the agents decision making working I felt satisfied enough).
The right tool for the right job...
Need to munge a file? PERL
Need to write an embedded application? C
Need to write a GUI? A JS framework (or Qt, or Motif/X if I'm feeling nostalgic)
Need to write a fast loop? ASM
Need to write a something stats-related? Python, R, JMP
Need to explore a computer science problem? LISP, SmallTalk (I don't know Haskell)
Need to work on a project that you're forced to? C++ :)
Let GCC/Clang solve that for you.
>Need to explore a computer science problem? LISP, SmallTalk (I don't know Haskell)
Scheme it's far easier.
Common Lisp's greatest strength is that it's "the programmable programming language." You can customize everything from the lexer to the syntax, and you can extensively customize or even replace the object model. It's trivial to write code that writes code.
There are some limitations. Haskell, for example, is less customizable but it works very well at high levels of mathematical abstraction.
Now, in practice, I don't often need the specific kinds of power that Lisp offers. Or rather, when I do need it, I don't need that power instantly at my fingertips. Completely customizing your programming language is something you should think long and hard before doing, and the median team will do it very badly. So I'm happy with the tradeoff offered by Rust macros, for example: They're harder to use than Common Lisp macros, so you only use them when you need them badly enough. Even for most above-average teams, I think it's a net win for macros to be a bit obnoxious to use.
But if you ever find yourself on a small team of incredibly talented programming language designers, and you're working in a problem space where no off-the-shelf language can do what you need, then Common Lisp is well worth a hard look.
Paul Graham's "On Lisp" is actually an excellent overview of the kinds of things you can do with Lisp. Norvig's first AI book is also a good demonstration of Lisp, even if the "AI" part is hopelessly obsolete at this point.
that's been a thing in ruby since probably forever and it's one of the defining things about it
Not wrong that ruby took a lot from perl, but it was heavily influenced by lisp and smalltalk and I'd personally argue those are the two largest influences.
It does seem that ruby was specifically designed to grab Perl programmers though. Several features match exactly.
It seems like the longer I am in software development, I find out that more and more things came from Lisp.
the OP was talking about dynamic languages... haskell and scala are not too surprising that they have implicit returns since they are functional paradigms foremost.
The way Lisp is structured means that almost certainly if you're missing language feature X you can bolt it on, stacking the new features on top of each other to make whatever abstraction you see fit.
It's the kind of thing that makes a Lisp head amused when someone talks about the genius of C# and LINQ (as an example). If you need an abstraction in Lisp, you can almost certainly build it in an ergonomic fashion that just doesn't have a parallel in other languages.
It's one of those powers you don't fully appreciate until you have it and then every other language seems hilariously inadequate in comparison. With great power cones great responsibility and it can all crumble with a lack of discipline (hence why I'm also a fan of ridiculously restrictive languages like Go), but honestly the sort of meta programming possible in Lisp has no equal I know of.
For ex I wrote about one such check here https://tech.perpetua.io/2022/01/generating-sqlite-bindings-...
This macro checks SQLite table/column references. Aka, if you try to access user_id when the table doesn’t have that column, the “user_id” text in your code will appear as a syntax error in your IDE and when you run the code.
The typed racket project is a bigger example. They added a typechecking system to the language, including a new typescript like variant.
I’m not aware of any other language where 10 lines of idiomatic code right in your codebase can add a new IDE warning.
To me it's more of a programmer's swiss army knife than a language I'd use in a big project that needs to be accessible to a larger team.
Lisp is simply a different way of thinking, in S-expressions. It's hard to explain but easier to show you, via the above link.
Haven't you ever thought "hmm, I could do this job faster if I had my own plugin/extension here?"
Lisp is really good for that, when used within Emacs. Extensions are very very simple, basically just the simplest functions inserted into your .emacs file.