Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unison Programming Language

unisonweb.org

Post reply on HN
Print view View original

81–90 of 134 posts

Re: The Unison Programming Language

#81

Post by adrusi »

brundolf wrote: post #59
dthul wrote: post #38

An immediate caveat I came across: if you want to look at some Unison code you need a special code management tool. Take for example their base library on Github: https://github.com/unisonweb/base The actual code lives in a sqlite file in the .unison/v2 folder. That would mean existing tools like version control and editors would need to learn about how Unison works in order to seamlessly support it. Also pulling out…

This is an interesting choice. Any language or framework has to make a dozen or more choices between doing something in a way that's compatible but compromising, or bespoke but... bespoke. It's always a painful choice in my experience. This one is particularly bold, though.

It's afaict a necessary decision, since unison is designed around the possibility of having multiple versions of the same function referred to be the same name.

Re: The Unison Programming Language

#82

Post by lamontcg »

slver wrote: post #79
lamontcg wrote: post #56

Earlier quoted context omitted.

Except 1.0.1 can fix a bug that one piece of code needs, while another piece of code can be happily bug dependent upon it. You can scream at the developers that they've violated semver but a "bugfix" is entirely subjective (relevant xkcd, spacebar heating, etc). And even when developers violate semver in a point release the problem still exists. They actually rarely, if ever, rollback with a 1.0.2 that is equivalent…

SemVer remains a pragmatic approach that works in vast amount of cases. It’s unclear what alternative we have here which works in more cases.

We don't have any better alternative, but lets not be naive about it when it comes to building bits of framework.

Semver would just be an artificial impediment at this level.

Re: The Unison Programming Language

#83

Post by mst »

Nullabillity wrote: post #78
umvi wrote: post #69

Earlier quoted context omitted.

I'm just as much of a novice as you, but one of the use cases the creators had in mind are distributed computing systems. For example, if you have to crunch a bunch of data in the cloud, you would write your data crunch function/algorithm (which is represented by some hash '#asdjh238ad') then spin up nodes to crunch data using '#asdjh238ad'. When a new node in a cluster comes up it can say "I don't have '#asdjh238ad'…

That makes sense as a build system (and is more or less how Nix works). The question would be why you'd subject your source code to this.

there was a paper that implemented an r7rs compatible module system for termite scheme that used hashes for identification for netework transfers of code but left the source files still normal - I think focusing on the textual representation too much misses the point a bit here.

Re: The Unison Programming Language

#84

Post by joe_the_user »

thom wrote: post #11

Super interesting, I was thinking about append-only codebases very recently: https://news.ycombinator.com/item?id=27492727 The implications of this, with the right frameworks and processes, seem potentially huge.

The thing is, the closest thing to append-only you have with ordinary programming languages APL and it's variants, where you can construct powerful functions with powerful primitives and methods for combining them.

But the thing is that APL quickly becomes a "write only" language - as far as I know, the main use of APL someone sitting at a brockerage who can cobble together any algorithm on twenty minutes and often throws away the result afterwards.

Which is to say, Unison is interesting because it seems to underestimate the importance of a program's code as document, as complete, coherent, human-readable, single-view, intentionally created text. Why hasn't the stream of ascii been replaced as the format of program in the last twenty years? It's a good question but the answer isn't that it's just matter of conservatism. There are several other things involved.

Re: The Unison Programming Language

#85

Post by the-smug-one »

asoltysik wrote: post #71
torginus wrote: post #40

Earlier quoted context omitted.

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…

> Storing the AST on the disk in a million files is not necessarily the best use of the filesystem A new codebase format just uses a sqlite database instead of a million files > Since the language is append only, all edits look like additions in version control Traditional methods of showing change in verson control, that is text diffs, don't make sense here anyway > Detecting that 2 things are the same through hashi…

What's the point of detecting that 1 + x + 1 is the same as x + 2 anyway? If I wrote it in one way, I meant it to be that way for a reason. Should it also be able to prove arbitrary code is semantically equivalent? Well, it can't do that for obvious reasons.

Re: The Unison Programming Language

#86

Post by slver »

lamontcg wrote: post #82
slver wrote: post #79

Earlier quoted context omitted.

SemVer remains a pragmatic approach that works in vast amount of cases. It’s unclear what alternative we have here which works in more cases.

We don't have any better alternative, but lets not be naive about it when it comes to building bits of framework. Semver would just be an artificial impediment at this level.

SemVer is an impediment only if you insist to make it so.

Re: The Unison Programming Language

#87

Post by acjohnson55 »

dcposch wrote: post #36
umvi wrote: 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…

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…

It knows what name you intended to use, because that's in your source, so I'm pretty sure it isn't a problem if implementations converge and diverge.

Re: The Unison Programming Language

#88

Post by acjohnson55 »

joe_the_user wrote: post #84
thom wrote: post #11

Super interesting, I was thinking about append-only codebases very recently: https://news.ycombinator.com/item?id=27492727 The implications of this, with the right frameworks and processes, seem potentially huge.

The thing is, the closest thing to append-only you have with ordinary programming languages APL and it's variants, where you can construct powerful functions with powerful primitives and methods for combining them. But the thing is that APL quickly becomes a "write only" language - as far as I know, the main use of APL someone sitting at a brockerage who can cobble together any algorithm on twenty minutes and often t…

It doesn't discard the text. The text, like the documentation and comments, are stored and re-rendered during editing. It's fundamentally textual. It just doesn't have to be stored as a one dimensional text stream.

Re: The Unison Programming Language

#89

Post by jackcviers3 »

torginus wrote: post #40
umvi wrote: 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…

Semver doesn't help in the case of transitive binary incompatibility. If lib A depends on B v2, and lib C depends on B v1, and application D depends on A and C, you cannot load a version of B that satisfies D, A, and C. Semver tells you that B 1 and B2 are incompatible, but not how to solve the issue.

Unison solves the issue - there isn't any binary incompatibility, because the transitive versions of Bv1 and Bv2 cannot be in conflict - the function references are to guaranteed unique and different versions of the art.

As for bug fixes - you can specify in your code exactly which version to use.

As for editors needing to be unison aware - they just delegate everything to the compiler via lsp and bsp.

Bug fixes are no more difficult than making the change. A new version is created, and your code can now depend on it. Old code will still run off of the old version. It's up to the code owner to decide to use the new, but fixed version.

Version control is all handled in the language itself.

As for the hard hashing problem... Runar is a particularly intelligent individual. I expect that his algorithm works pretty well.

The first argument about storing the ast is moot in an age where cached compiled typescript, Python, and .class files take up inordinate amounts of disk space.

> Solutions that dynamically discover code dependencies and automatically run tests exist for both procedural and functional languages

Eh. Piping and yarn ain't got nothing on maven and ivy and apt. But yes, dependency management isn't anything new under the sun. Dynamically resolving individual function versions in packages alongside binary incompatible functions is.

Re: The Unison Programming Language

#90

Post by deanstag »

This is really exciting. I might have missed this in the documentation, but is there any way of grouping/tagging together a set of functions, just so that conceptually similar functions can be browsed together? For traditional languages a folder/package/file performed this functionality.
Post reply on HN