Live data from Hacker News

The Unison Programming Language

unisonweb.org

121–130 of 134 posts

Re: The Unison Programming Language

#121
post #20

> Run ucm init to initialize a Unison codebase in $HOME/.unison Ugh, this conflicts with my favorite file sync tool: https://www.cis.upenn.edu/~bcpierce/unison/

FYI you can do ‘ucm -codebase /someplace/else init’ to initialize a codebase in another directory.

And then ‘ucm -codebase /somewhere/else’ to launch ucm.

Also I’m not sure what Unison the file sync tool stashes in .unison or how it uses that directory but there might not be any conflict. UCM will just create a .unison/v2/unison.sqlite3 file.

Re: The Unison Programming Language

#122
post #6

I had a really hard time wrapping my mind around this just reading the website alone. If you are in the same boat, watch the first 10 minutes of this video at 1.5x speed: https://www.youtube.com/watch?v=gCWtkvDQ2ZI and it will make so, so much more sense. ...and if you are like me you'll probably need to read this twitter thread to get the answer to your #1 question: https://twitter.com/unisonweb/status/1173942974381…

I'm not totally convinced by this. - Storing the AST on the disk in a million files is not necessarily the best use of the filesystem. In contrast, most languages store text files on the disk, and build up a similar AST in memory only - You can't view your code without special tools, which means all text editors/version control etc. need to be Unison-aware - Since the language is append only, all edits look like addi…

Honestly, programming without language aware tools in this day and age is very inefficient. Sure, in a pinch you can use a text editing program to edit stuff, but it wouldn't be so hard to install the standard editor in that case.

Re: The Unison Programming Language

#123
post #36

Earlier quoted context omitted.

Cool to see people thinking this big! One challenge I foresee is unintentional coupling. Say you have two functions: func serialize(MyRecord) ... func debugToString(MyRecord) ... Now if you ever make the mistake of having giving those the same implemention, then in Unison they'd be the same hash reference, right? Then if you want to update, say the debug print later it would update all callsites for that hash includi…

Hello, Unison author here. This is definitely an issue that is real, and is currently a problem, and that we will fix; probably by giving the function author an option to salt the hash of new definitions that have some semantic meaning beyond their implementations (appropriate for most application/business logic). No salt for definitions whose meanings are defined by their implementations (appropriate for most generi…

Why not simply record where each reference occurs and ensure that if one definition is modified, the other is not? The programmer shouldn't have to think about salting any hashes, it should be automatic and hidden under the hood.

Re: The Unison Programming Language

#124
post #104

Very neat project! One question about content addressed programs: how does this play out with types that are structurally equivalent but semantically distinct? For instance, assuming C definitions, an integer and a file descriptor have the same content but probably should not be treated as the same type (I wouldn’t want arithmetic to type check against file descriptors…). Another scenario: say I have a type “Foo” whi…

It looks from the other discussions that it's specifically content-addressed, not "semantic-addressed", so if your code has any redundant syntax (the given example being `x -> x + 2` vs `x -> x + 1 + 1`) it's still distinct.

In that case, I guess data types can have a 0-size marker member, kind of like Rust's `PhantomData` type, that could ensure distinctness.

Re: The Unison Programming Language

#125
post #6

I had a really hard time wrapping my mind around this just reading the website alone. If you are in the same boat, watch the first 10 minutes of this video at 1.5x speed: https://www.youtube.com/watch?v=gCWtkvDQ2ZI and it will make so, so much more sense. ...and if you are like me you'll probably need to read this twitter thread to get the answer to your #1 question: https://twitter.com/unisonweb/status/1173942974381…

This reminds me of Kubernetes, where all cluster state is neatly structured and placed in a replicated data store (etcd) that is the source of truth for operation, with the right parts immutable (e.g. volumes).

The first thing people do is check in textual representations of those things in version control and operate on that instead.

Re: The Unison Programming Language

#126
post #54
post #33

Earlier quoted context omitted.

That's kind of the thing that makes APIs possible, right? It sounds to me like "what if programming were done in a completely flat global namespace in which abstractions, encapsulation, and structure were impossible."

No. An API specifies more than the name of the function. It will specify the arguments, their types, the type of the return value, and at least informally, what the function does. You can change the underlying implementation without changing the API. That's the whole point of an API. The problem with current API technology is that the informality of the spec of what the function does. That allows some aspects of the…

Reading this now, I'm imagining all the horrors of static linking but applied to every function instead of whole modules.

Maybe the simplest solution is to allow the function to change to the new version, but make it easy to revert in the event that something breaks. This of course means that you can't make the names of the functions their hash (without lying, preventing the runtime from checking that hashes ways match, or modifying emitted bytecode or native code to do what you want), it has to be an orthogonal layer on top of them like types (as I mentioned elsewhere in the thread).

Re: The Unison Programming Language

#127
post #36

Earlier quoted context omitted.

Cool to see people thinking this big! One challenge I foresee is unintentional coupling. Say you have two functions: func serialize(MyRecord) ... func debugToString(MyRecord) ... Now if you ever make the mistake of having giving those the same implemention, then in Unison they'd be the same hash reference, right? Then if you want to update, say the debug print later it would update all callsites for that hash includi…

Hello, Unison author here. This is definitely an issue that is real, and is currently a problem, and that we will fix; probably by giving the function author an option to salt the hash of new definitions that have some semantic meaning beyond their implementations (appropriate for most application/business logic). No salt for definitions whose meanings are defined by their implementations (appropriate for most generi…

This seems to be very developer hostile.

Not only do they have to provide a salt themselves but on top of that, they need to make a judgment call of when something has "more semantic meaning beyond their implementation" (to use your words) rather than being some more "fundamental" code.

I'm also surprised that you haven't solved this problem yet: at least once a day, IDEA warns me that some portion of my code is duplicated exactly in some other area of my code, so this kind of duplicated logic is already quite common.

Re: The Unison Programming Language

#128
post #94

Earlier quoted context omitted.

Semver is an uneasy compromise at best. Rich Hickey has a nice talk that digs into the principles around changing software. Once you see this POV, you are unlikely to view Semantic Versioning as anything other than a messy hack. I'm not saying it is worse than nothing, but sometimes ideas have a way of sticking around too long and making people comfortable.

The talk for those interested: https://youtube.com/watch?v=oyLBGkS5ICk

And the transcript: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

Re: The Unison Programming Language

#129

Earlier quoted context omitted.

Sounds like trading one set of problems for another.

Tangent: here's what I find fascinating: when we evaluate which algorithm or data structure is best to handle a given situation, we know how to reason about algorithmic complexity and pick a best option for our situation. But then when it comes to ideas like this we just tend to say "we're trading one set of problems or another", as if we can't evaluate the problems in a similar manner. And I'm not picking on you her…

I would like to note that even with algorithms/datastructures "best" is USUALLY not the word (even assuming that all algorithms/structures are discovered/known). "Good enough" / "fits in my multi dimensional budget" is reality:

(0) It is easy to order two real numbers. 1 is greater than 0. But can we order points on the cartesian plane (1,2) or (2,1) or (0,100000000000)? Already at 2nd dimension not all points are easily ordered. There is solution "just give priority to 1st coordinate", but can you really completely disregard memory usage and focus solely on cpu?

(1) Theoretically, to get "best", one needs to evaluate not only O(n) of avg cpu usage, and avg memory usage, but also worst and best cases, while using knowledge of input data distribution (e.g. maybe input is almost sorted). Memory access patterns, cache locality, battery life, suitability for your hardware also must come into play. (many dimensions)

(2) Practially one has to do profiling on real hardware with real configurations / inputs / workloads. Different workloads may favor different algorithms/structures. (again results with many dimensions)

(3) Due to constrained time people will not even go over all algorithms. Real people will immediatly rule out really bad ones, then pick 1 or 2 algorithms that theoretically are good enough match, and see if their profiling results fit in cpu/memory budgets. (even if budget is not on paper, but just part of intuition)

Re: The Unison Programming Language

#130

Earlier quoted context omitted.

Sounds like trading one set of problems for another.

Welcome to software engineering where there is no golden bullets, only different tradeoffs :)

There are also circles of hell. (opposite of silver bullet)
Post reply on HN