Integrate ideas from unison

Hi, @stephenBDT !

I've been aware of Unison for a while, but I never dove too deeply into they ideas of the language since I already had a lot on my plate and I thought it best to save it for later.

However, I felt prompted by your comment to take a look and I got to watch/read some resources to get an idea of what Unison proposes.

I checked out the following videos, and the Unison website ( https://www.unisonweb.org/ ):

If you feel that my opinion about Unison is mistaken or uninformed and you have some material you'd like me to look at, please send it my way and I'll take a look.

Regarding Unison's ideas:

The idea of having your code be addressable by hashing its content and only using names as aliases for the hash sounds interesting; however, I'm not convinced it's valuable on its own.

One particular problem that you run into is that programming tools/infrastructure currently assumes programs are made out of text, and getting out of this model imposes you with having to build custom infrastructure to replace already existing (generic) tools.

Currently, they're running into that problem with git/github, where the infrastructure doesn't fully support diffing/patching in the usual way, and they have to come up with some trickery to get something that kinda works, but in the long term they're going to have to make their own substitutes for git/github, and perhaps other tools as well.

Now, having to come up with alternative tools isn't a deal breaker, if the value this new approach provides justifies such an investment of effort. However, I'm not convinced the value provided is great.

They advertise Unison as a sort of append-only language. Code is fundamentally immutable, so when you modify a function, the old version still lives on in your codebase, even if it's never referenced by any other piece of code ever again (Unison works as a global DB in your hard-drive which stores all code across your projects).

On the face of it, this just seems... silly to me. I don't want to be disrespectful or dismissive, but I can't imagine this being useful. Perhaps I'm being too close-minded or I'm failing to see an important use-case, but even when you store multiple versions of your code-base as it evolves in a tool such as Git, it's not like every time I save a file I end up with a version of a function somewhere in my hard-drive that will never be used for anything ever, because I'll make an updated version in the next 5 minutes.

And the benefit of that is going to be that changing the names of things (i.e. one use-case for refactoring) is going to be easier now? I'll replace my generic tools for Unison-specific ones and litter my code-base with one-off artifacts just to make something easy just a tiny bit easier?

They do say such an approach would be a solution to dependency hell, and I agree that it would provide a solution. But I think you can have equally (if not better solutions) without going to such extremes. I came up with a solution to dependency hell a few years ago which I've been wanting to introduce to the Lux community in the near future. That solution requires no new technology and it's just a matter of changing a few things about project structure and package versioning schemes. I haven't talked about it since I didn't want to talk about stuff that I was only going to get into after v0.6. But, knowing that I can solve dependency hell without a gigantic engineering effort, I'm not impressed by Unison's argument that making code content-addressable is the way forward.

Again, perhaps I'm not considering things properly, but it just sounds silly to me.

The one thing that Unison does bring up as a somewhat valid use-case for this approach is with distributed computing. But even then I have my gripes.

The folks behind Unison seem to have a prescriptive approach to distributed programming. Basically, they believe the correct/proper way of doing it is by having a network of Unison servers that are able to share code with one another. So, if node A wants node B to perform a computation, but node B does not have all the necessary code, node A can transfer the code to it. And since code is content-addressable by hash, there will be no naming clashes when it arrives at B, and you won't have to worry about any resulting runtime exceptions.

I have 2 issues with this:

I don't approve of programming languages prescribing things to programmers. I like the idea of languages giving people options, and even defaults. But I hate it when a language tells me "this is how you're supposed to do this". So I'm not amused by Unison trying to justify the content-addressable element by telling my it must be that way because I'm going to be doing distributed programming the way they want me to.
I'm not convinced that I have to buy into the content-addressable-codebase-as-append-only-database stuff in order to go with that way of doing distributed programming in the first place. So them bundling those 2 together and selling them to me as a package feels illegitimate. Even if I did agree with their way of doing distributed computing, I still wouldn't buy the content-addressable code part.

I feel like Unison asks more from me than what it offers in return. I'm not someone who is easily impressed by novelty. Something is either good or bad on its own merit; and I'm not convinced Unison's approach is the way to go merely because it disrupts the current way to do programming.

With that said, I like to believe that I'm an open-minded guy. I have no doubt in my mind that the guys behind Unison are pretty smart and capable fellows. I just happen to think their efforts are misguided. In the event that their efforts yield good results, I'm more than happy to swallow my pride, accept that they were right all along, and try out some of their ideas. However, I feel it is more prudent for me to just watch how it goes for them, instead of joining their approach now.

I apologize if I seem overly harsh in my analysis of Unison. I'm a pretty opinionated guy, but I do not enjoy criticizing other people's work, because the reality is that I don't have all the answers, and I don't know what the future has in store for Unison. I honestly want those guys to succeed, if only because I want to see more diversity of ideas and approaches in the programming language world. But as it currently stands, I'm not convinced that their ideas are the right way.

Thanks for bringing this subject to my attention, and if you're curious about Unison, please give it a try (if you haven't already). I'd love to hear about people's hands-on experience with Unison.

LuxLang / lux

Integrate ideas from unison #56

Regarding Unison's ideas: