Clojurians Log v2

Well that didn't take long. Repos with free agents attached: https://claude.com/contact-sales/claude-for-oss

I'm tired of pretending their logo isn't a butthole

Lol

i’d make a bytecode that runs on an abstract virtual machine that has strong promises of backward compatibility

i’m interested to hear your ideas. i like the state of it, but i suspect i’m just complacent with the current world

Inevitably, some will mention Unison and I will say "not that".

There's a bunch of ways in which code is not data, even for clojure. Instead, it is text oriented and file oriented. I've been thinking about this just in the context of clojure, and I think there are ways to start moving towards code as data.

I'll highlight some freedoms then You can decide on a different artifact format than jars, different metadata format than poms, different authentication and management structures for repos, entirely change what a "repo" is, etc

having more options isn't necessarily better (it's also not necessarily worse). I think it's better to frame how things should be different around what problems you are trying to solve.

As just one example of a problem. A lot of utility functions in clojure are just a few lines. There's not really a convenient way to grab just the utility function and its dependencies.

I have very mixed feelings about the strong separation from native code in the jvm. But would weakening that weaken the safety guarantees you get so marking larger systems would be harder

Packaging, distributing, and loading native resources for jvm libs is a huge pain.

Not quite the same, but packaging, distributing, and loading large application resources is also painful.

It would be interesting to redo something very maven like, but instead something like a DHT storing artifacts

Part of the problem with native resources is that if you're targeting linux, then precompiled binaries often don't help (it's usually ok on OSX and Windows).

Again tricky, might cause adoption issues, how do you police what does in the DHT, mavens kind of loose federation around the big central repos may be best

There was some suggestion I saw somewhere to use ed25519 (64 bytes?) signatures in versions

What is a DHT?

Distributed hash table

P2P

Yeah, artifacts as globally addressable URIs

Js vm deps resolution is handy in that regard

Some distributed, federated rdf scheme or a crdt, that hosts "repos"

Torrent swarming for deps downloads

The Unison approach is a great idea. I’m building a strong type Lisp with Unison’s content-hash concept and a simple interop feature like Clojure. The main platform is JVM.

I'm asking a genuine question here - what properties of DHTs and artifacts as globally addressable urls are desirable (for jvm stuff) and how many of those are equally delivered by doing a torrent like thing just for artifact retrievals

If that's not a well-formed question let me know or just rant what's in your head

In some ways because a DHT is on its face "untrustworthy" because there is no central authority, it would force things like signature checking

In some ways it is solving a social problem with tech, making a community resource run in a p2p way

I'm a bit of an information anarchist. I think information wants to be free. A hacker ethic of sorts. And with it comes an ethic of decentralization and distributed trust. Git deps for clj is an escape hatch to a global uri scheme. It's a url with source hanging off. That could be an ipfs resource or some future unison uri like thing. Does unison solve trusted vs untrusted code? Can it block user scripts in domain code? I feel like you need a metered sci runtime to sandbox untrusted code.

@smith.adriane can you elaborate on the Linux native libs issue?

And I read something recently - that I will try to find the link for - which called repositories something like "a wicked problem" where the way you formulate the problem statement determines your solution

And there is no solution which will make everyone happy + it's all constrained by social realities

I don't think my problem statement would include "things should be more trust-less."

Rather more things like "development should be funded and compensated" and "transitive risks should be made visible"

Does it include runtime foreign dep injection?

or runtime dep resolution

@john I think I would describe that more as "information libertarian" - very crypto bro coded

I think it's an ethic that came before crypto

But yeah I think a lot of crypto bros ended up camping out in the same intellectual waters. There's some overlap in philosophy. Maybe different motives.

Things like the right to encrypt arbitrarily. If you're invested in algorithms that require encryption freedom, you're going to have stronger opinions over your rights around that.

Found it https://nesbitt.io/2026/01/23/package-management-is-a-wicked-problem.html

https://nesbitt.io/2026/01/22/a-protocol-for-package-management.html

Another banger

I think part of why requiring single functions and their dependencies by hashes doesn't appeal to me is simply because I think there are multiple granularities of usage

Leave off the of usage for a second. I'll think of the better way to describe it

But a human being or group of human beings developed software

Then that software is bundled into artifacts

Then your software consumes a portion of the functional behavior of that artifact

I think the part that matters more isn't the artifact in the middle - which is what most schemes focus on

And I also don't think it's the usage chain at the bottom

I think it's the very top. You depend on multiple artifacts written by Joe schmo in Lansing Michigan. Joe schmo is not funded. He also does it in his spare time. It's the xkcd comic all the way down.

My hypothesis is that this only has worked so far because software as a field has been generally lucrative. IE even the people doing it for free in their spare time probably have a six-figure job and that subsidizes their work

If that ever changes, or we reach the actuarial expiration date on a lot of these folks, we'll hit a kind of software maintenance collapse

It's theorized to be a "gift economy" that only happens in a surplus/abundance scenarios, yeah

"The Cathedral and the Bazaar" frames it that way IIRC

It's not that I think there should be a central authority on what gets published or not - it's that I think trust relationships should be made explicit, rather than implicit

The relationship exists regardless

Like sonatype has a thing where they will fund through subscriptions to their service the most popular packages. That's not bad, but I think we all know that most software has a dependence on a long tail of small libraries.

part of why I wanted to hear other people's solutions is because I think I can work backwards from their solution to problems they see

That is basically the great man theory of history applied to software right? There are these libraries that people depend on and they come from these unique individuals and couldn't come from anywhere esle

That's an interesting perspective

No - it's not they are the only people who could maintain these bits of software or could have produced them - it's that they are in reality only maintained by one person

Our repositories do not represent the concept of "I want this software artifact, but it's maintained by company B instead of company A"

But relationships like that do exist once you step outside of the repositories. For instance the jvm itself

You download the jvm which is a source repo, then that is built into artifacts and distributed under terms by different providers. Oracle Amazon Google, etc. are all providers you can get "java.desktop" from

Whereas once something gets on a maven repo you can pick a different repo or do a lot of things manually - but ultimately org.clojure/clojure is only available from one provider per repo

So I don't think it's "the great man theory" but I also don't think it's your classic venture capitalist "all the devs are interchangeable" either. Maintenance of a software artifact requires domain knowledge if nothing else. I'm sure we can find (or build up) another curl maintainer, but no one is actually incentivized to be the curl maintainer

If an open source project has no "maintainer" then the consumer becomes the maintainer. I don't see the problem. How is complaining about having a dependency on an unmaintained artifact anything other than saying, "not it!"?

The problem is that that does not happen in practice

I guess it's the fact we take it for granted and are mostly blind to it

yeah

It is the view that where we are now is important so what got us here must be important

(I don't know that the group that brought us the ideas of rockstar devs and 10x programmers can be entirely characterized as having an interchangeable view of devs)

Well hey, AI makes maintenance easier now. In a few years, every repo will have a free agent attached. Repo owners will have more automatic actions for maintenance related activities.

What are the chances most human repo owners are merging commits from mostly bots in 5 to 10 years?

We may be trying to advertise clojure to agents in the future, trying to get them to use our language, so that they choose to build in it. What open source projects will billion dollar agent economies sponsor and donate maintenance resources to?

hmmm, is targeting advertisements towards agents a form of injection attack? 🤔

I guess advertisements in general are injection attacks lol

A lot of VC culture can be characterized as contempt for the masses, and worship for heroes, so very great man of history

@john counterpoint, that's insane

Anyways, I guess I have no choice but to write up what I'm thinking

I kinda love the square brackets 😆

Cool, but square brackets ? Really ?

Lol it's opinionated

Super interesting type system

Ya, it's just one of those irks that will be irrationally hard for me to get over. Just like how I didn't Ruby style begin/end 😅

In terms of convenience I can see why square brackets could be good, because to make a ( I have to shift+9 (two keys) whereas a square bracket is just one key.

Depends on your keyboard layout. On a Danish layout both are two keys, shift+ or altgr+.

I do find the argument for using square brackets a bit… underwhelming? > “Square brackets replace parentheses for a clean, uniform syntax.” Are parentheses dirty? Do two parentheses not look uniform?

But the type system does look interesting.

I program with a US ANSI layout, but in my native Estonian keyboard it would also be 2 keys for both I guess (I got used to programming in US ANSI because 2 decades ago when I started learning HTML, the < and > were very uncomfortable in my own languages layout).

I one time wondered what it'd be like defining forms with vectors and applying them with parens, might be an interesting mix. So you don't have to worry about function application in bracket form. Could be neat for some kinds of macrology. Don't think they're doing that here though.

Okay.

See #ai-assisted-coding.