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 don't think Lisp, Scheme, OCaml or Haskell talks have been submitted yet actually.
https://blog.carolina.codes/p/call-for-speakers-is-now-open-...
If you decide to submit a talk, the deadline is May 25th.
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.
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.)
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.
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.
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.