Many times in my career I had the freedom of choice in regards to language and technology to use in a project.
Even though I know Lisp (to some extent), whenever I tried to prototype what I needed in Common Lisp or whatever, the lack of libraries, documentation and community, was basically killing my attempt.
Sure, if I lived forever like a Strugatski brothers character, I could write my own libraries, package manager, wikis and whatnot. But I don’t.
Whenever I read an article like this I get excited again about the Lisp prospect, but then I remember the past!
I’ll just be the voice that says “my experience is different”. I have prototyped and run in production© programs in Common Lisp. They involve(d) connecting to a SOAP service, fetching an API, sending data to a FTP, reading an SQLite DB and showing data on a website (using Sentry in production), selling products with Stripe, sending emails with Sendgrid. I only wrote two straightforward libraries (string manipulation, a 10-lines interface to Sendgrid’s API), and I learned a lot by writing documentation. I can’t write Python nor use its buggy ecosystem anymore! (just last week, a pip 20.0 bug made it impossible to rollback to 19.3 or upgrade to 20.0.1 with pip itself, it fuck** my venv)
edit: helpful links:
Same here, I always revert to CL when prototyping or doing exploratory programming that end up as programs that stay around. Also at work, for talking to Jira for example.
It really depends on your environment and needs, but libraries, documentation and community have rarely been an issue and I don’t think Clojure is going to help the OP in this regard if it is a problem for CL.
I’m always curious why CL is so divisive in this respect (leaving out the community). Why are libraries for some such an issue? Even if something is missing it is easy to make something solid yourself.
Hell, I even made two mobile apps recently.
Same. I did trading bots, distributed embedded systems, signal processing in CL. I see the issue of “insufficient ecosystem” once in a while on the Internet and always puzzled what is that people do to have this problem.
If I had to single out a clear weakness it’d be the native GUI, but outside of that…
So, where do you find your libraries then?
Most of them are in quicklisp (a popular repo system for CL) and are a one line away from installation. There’s tons of stuff really.
Can’t speak for original poster, but I’ve been surprised how much I’ve found with just a Google search with “common lisp” appended. To be more concrete, when I went looking for them, I found a nice ORM with an SQL generator, a Twitter API client, Vulcan bindings, etc. I can believe that there are some gaps though. It feels a bit like there was a lull in activity in the late 2000 early 2010s, and then perhaps a more recent pickup? You definitely find code that’s five years old, and code that was updated in the last week, and not much in between. I think discoverability may have taken a hit when Quickdocs shut down last year – Quickref doesn’t have a built-in text search, although honestly it still pops up in those Google searches.
The libraries are mostly by individual coders or small groups, though, rather than corporation-supported frameworks. I would say it’s a bit more discoverable and usable than, say, the Haskell ecosystem, though of course nothing like Perl/Python/Node levels of availability. I like Quicklisp as a package management system, though CLPM is an intriguing new development.
Hi, start with this list, sufficiently curated to be useful: https://github.com/CodyReichert/awesome-cl
In this case you could probably give Clojure a try. While I disagree with some points from this article (static typing and TCO among them) Clojure definitely has the libraries (or rather, wrappers), package manager, wiki and whatnot.
I tried doing some Clojure/Clojurescript stuff, and I found that Clojure kind of lacked “big picture” documentation around its core APIs. There are docs for functions, but it’s often very minimal and so when you’re looking at a new API it’s hard to figure out the core concepts.
I think a lot of the concepts have high-level guides somewhere, but it’s kind of all over the place. I think Clojure targets people more patient/“better” than me. But I think, for example, that Clojure’s edn package docs could look more like Python’s pickle package docs and everyone would benefit (I’m counting the edn github post as part of the package docs).
Though, to your point, you can always “downgrade to Java” super smoothly when you want third-party stuff. And the stack, you know, works (the biggest problem I’ve had as a beginner was around tooling but hey, I use Python and JS for a living, you have to make things pretty busted to scare me)
It’s not clear why TCO needs to be supported by JVM if the optimization is already done by the JVM code generator. Clojure must be fine in that respect.
The JVM can support tail recursion but not generalized tail calls. (JVM bytecode does not allow goto to cross method boundaries.) But I don’t think the author actually understands this level of nuance and instead just says “JVM bad” and ignores that many other non-lisps (like Lua) do in fact have TCO.
The author says “the JVM does not support it [generalized tail recursion], … so, I always view any functional language targeting the JVM with great suspicion”. In my reading, this is far enough away from “JVM bad”.
Some Lisp users are very fond of their abstractions and telling them “it has TCO, you just have to use recur” might not sway them that much.
Fair; I honestly didn’t finish reading the article because the tone felt too cheerleader-ish at the top, and because I hate it when articles tell other people what they should do.
Exactly; there’s no reason a good (JIT-)compiler can’t do that. However, Clojure does not do that. It relies on hacks like recur to have the programmer manually inform the runtime that they want tail calls.
I happen to love clojure, partly because it is happy to break from Lisp tradition.
However I’m not here to discuss Clojure. I think the author needs to see a good static type system, like in Haskell or Ada. Haskell it seems, when the types line up, your program will work. Ada allows you to encode these invariants into the type system. Both would address the author’s frustration at static type systems.