3 ms·
My honest take is that if someone truly loves CL and wants it to get more hacker attention, it would greatly, greatly benefit from someone greenfielding a moder
by troad 10mo ago
My honest take is that if someone truly loves CL and wants it to get more hacker attention, it would greatly, greatly benefit from someone greenfielding a modern package manager for it.
That is to say, a cargo/zig/mix/golang-style all-in-one CLI tool that has opinionated defaults, reasonable basic functionality (HTTPS, hashing, lockfiles) and is approachable and frictionless. `cl init my-proj`, `cl test my-proj`, etc.
To be entirely frank though, I never got the sense that the CL community is interested in that kind of onboarding, so I expect the language to continue its steady slide into senescence, sadly.
- atgreen 10mo agoYou need to learn about ocicl: https://github.com/ocicl/ocicl https://github.com/ocicl/ocicl It does all of this and more.
- troad 10mo agoI am aware of it. I don't think it's equivalent to the tools I mentioned, though it is definitely an improvement on mere ASDF/QL. The problem with ocicl is that it's more brownfield than greenfield -- it's fixing the existing packaging, but not doing much to rethink it. The tool I am thinking of would need to (a) be able to download, manage, pin (etc) various CL compilers, (b) offer a REPL as interactive as e.g. irb, (c) offer comparable features and ease of use to something like cargo. That is to say - language management, project management, package management, accessible at logical keywords under an all-in-one tool. CL's soul is the REPL, and yet by default the average newcomer can't even use arrow keys or backspace in SBCL. Sure, sure, they should use rlwrap, but they'd have to know that exists, and they generally don't. So they'll go back to Python or Node, and not worry about a language that can't even figure out backspaces (from their perspective). CL has a lot going for it, but also has a lot of cruft, that its users are used to, but which is off-putting to newcomers. Not every bit of esoterica about the historical implementations of CL is in fact important or even useful, and CL is absolutely buried in it. Both OCaml and Haskell have invested heavily in their tooling recently, to good effect. CL... not so much. It would take a very confident hand to hack away the weeds, but I don't see another way forward. CL can be a vibrant tool into the future, or it can become (remain?) a museum piece.