After learning Python, I wanted to take the next step and find what was better. I looked into a lot of languages reading books on Haskell and Lisp and many others. At least for my use cases (desktop scripting, numerical work... etc) I didn't find Lisp to be superior. Most of what I actually needed to do could be done simpler in Python. Python's REPL isn't near as good as CL, but it's good enough. Then the batteries included was huge. So practically any task I could whip something up pretty quick. There are definitely some areas where Lisp is obviously superior to Python such as performance of plain code or things such as grammarly that would've likely been harder in python. I just think for the vast majority of programmers, enough good parts were pulled from lisp.
As a Lisp fan who sometimes codes in Scheme and Common Lisp whenever I get the chance, I agree with you. The gap has certainly narrowed in the past 20 or so years between Lisp and widely-used programming languages. In addition, the rise of statically-typed functional programming languages like OCaml and Haskell provide another alternative for those who love functional programming but want Hindley-Milner types.
I still think Lisp, whether in the form of Scheme or Common Lisp (I haven’t tried Clojure), is quite enlightening due to the immense flexibility these languages provide. However, I’m reminded of the rationale of MIT’s decision back in 2009 to move away from SICP and Scheme in the intro CS course in favor of Python: the vast majority of developers aren’t building new ecosystems from the ground up, but are instead reliant on an ecosystem of libraries. Lisps are wonderful for creating whole worlds due to the powerful tools they provide. I’m currently working on a side project where Lisp’s flexibility comes in handy. But if I’m effectively gluing together APIs to build a solution (and this is not an insult), then do I need macros, MOP, multiple dispatch, and homoiconicity? Thus, many programmers do not need the full power of Lisp to get their jobs done. There’s also the fact that languages like Python and JavaScript have a lot more commercial and community backing than Scheme and Common Lisp.
If I’m writing something complex like a DBMS or web browser, then Common Lisp would be one of my first choices. However, if I’m writing a machine learning application or a web application, then I’ll most likely reach for Python or JavaScript, respectively, due to the library ecosystems.
I feel exactly the same. I wish I did something cool enough to require the full power of lisp, but generally speaking...I just need to glue some stuff together. Other people will have different needs though. I can still appreciate the beauty of lisp and I'm glad its out there in case I ever need it!
Oh, and I do use CL's super powers during development: interactive debugger, restarting a point in the stackframe, fast and incremental compilation, good type checks by SBCL… and I get a fast binary.
Learning didn't come without a few gotchas, but they're all better documented out there now.
If you have any interest in submitting a talk for a polyglot conference in South Carolina this August, you're talking about several languages that haven't yet been represented in the submissions.
I don't think Lisp, Scheme, OCaml or Haskell talks have been submitted yet actually.
> if I’m writing a machine learning application or a web application, then I’ll most likely reach for Python or JavaScript, respectively, due to the library ecosystems.
This sounds eminently sensible but it never pans out that way in practice for me:
How do you understand the ML algorithms if you haven't implemented them yourself?
And if you have implemented them for the sake of understanding, in whatever language you fancied, why not just keep using that implementation?
The reason I'd choose Python in practice would be as a social compromise with collaborators.
(I say this having recently switched from Julia to Common Lisp because I didn't feel the ecosystem was giving me much practical benefit.)
Do you drive a car you built from scratch? How can you drive from A to B without first understanding how a car works by building one? And since you already built one, why not just keep using that one?
Or maybe you have built a car. But did you type your message on a computer you built yourself using some silicon and a home-baked x-ray lithography machine?
I definitely think there can be value in reimplementing something for educational purposes, but often knowing how to use something without necessarily being able to build it yourself is just fine. And those things you do build for educational purposes should almost always be abandoned after serving their educational purpose.
My limited experience with probabilistic sorts of programming though is that the risk of misunderstanding/misuse is very high relative to the implementation complexity. Cars and. X-ray machines don't have simple implementations.
Often very little code but a lot of opportunities to goof up one assumption or another.
But yeah I'm probably overgeneralizing from limited experience.
The one thing that I most wish Python had is Common Lisp's restartable conditions. They're like exceptions but they don't break your whole process if you don't handle them in the code. If you forgot to define a variable, you'll have the option to define it and resume computation. If you forgot to provide a value, you'll be able to provide one now and resume computation. As it is, Python just dies if something unforeseen happens, which feels like a missed opportunity given that Python is a dynamic language (for which it pays a price).
I work in ML, and launching a job on a cluster just to have it fail an hour later on a typo got old ten years ago. Being able to resume after silly mistakes would easily reduce debugging time by an order of magnitude, just because I need to run the job only once and not ten times.
> After learning Python, I wanted to take the next step and find what was better
Elixir and Golang. Both are learned quite easily and offer a lot (Golang's ecosystem is bigger but Elixir's is very focused and has all the standard stuff you will need).
If you are willing to spend more time and/or care about resource usage -- Rust.
