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

71–80 of 134 posts

Re: The Unison Programming Language

#71

Post by asoltysik »

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…

> 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 hashing is nontrivial, can it detect that 1 + x + 1 is the same as x + 2? The ASTs are differen

It can't detect that. It if could it would be pretty cool, but I don't think it would improve the usability too much

Re: The Unison Programming Language

#72

Post by ajuc »

aparsons wrote: post #63
ajuc wrote: post #48

Earlier quoted context omitted.

> The names are just pointers, and they're both pointing to the same definition in your example. But when you redefine one of those, you would point one of the names to a new definition. But how do you know which name was called where if the callers referenced the content hash not the name?

Would it not be correct for those callers to keep calling the old (shared) implementation?

well it would be nice to have a way to update old code

Re: The Unison Programming Language

#73

Post by Nullabillity »

fastball wrote: post #67
torginus wrote: post #51

Earlier quoted context omitted.

You are right - but choosing the correct solution imho needs to be done with human oversight - I think a semver based dependency resolution works great here, for example if bar requires foo 1.0 and baz needs 1.0.1 they will happily use the same version, but if baz used foo 1.1 they would use the separate ones.

I think another key idea is that you're still thinking about libraries as complete packages where you kinda install two versions of the same thing. But it seems more likely in the Unison ecosystem that you'd end up with the ability to much more easily only extract the specific functions you need. So say there is v1 and v2 of a utility lib in my dep tree, but actually only using func A from v1 and func B from v2. Then…

You still need some unit of atomicity to be able to maintain invariants. You can't combine HashMap_LinearProbe::insert with HashMap_Chains::remove, because they both depend on implementation details in order to maintain HashMap's invariants.

Re: The Unison Programming Language

#74

Post by milansuk »

ajuc wrote: post #48
sgk284 wrote: post #39

Earlier quoted context omitted.

The names are just pointers, and they're both pointing to the same definition in your example. But when you redefine one of those, you would point one of the names to a new definition. It's similar to how DNS can have two domains point to the same IP, but then you can change one of those domains point to a new IP.

> The names are just pointers, and they're both pointing to the same definition in your example. But when you redefine one of those, you would point one of the names to a new definition. But how do you know which name was called where if the callers referenced the content hash not the name?

I also think that the DNS analogy is wrong because all callers are hash-based. The only solution I see is to go through the list of all callers and manually update selected ones.

If I understand Unison right, the names are used only on the developer's layer(to write code), but when you save code, it's all hash-based.

Still, Unison got my attention.

Re: The Unison Programming Language

#76

Post by agbell »

0_gravitas wrote: post #23

I've been semi-closely tracking this project for a while, and imo it's easily __the__ most interesting project I've seen in the sphere period. Serendipitous-ly, I came across an interview a couple weeks ago with one of the main bodies behind the project on the Corecursive podcast (from early 2019) (I think their name was Runar Bjarnason). Had no idea until it was mentioned almost offhandedly in the last few minutes!

I think this is the episode you are talking about [1] Runar and Paul a huge inspiration! I'm not totally sold on this idea as practical, but I think it will get there and while they have a lofty goal, I certainly wouldn't bet against the pair of them.

[1]: https://corecursive.com/027-abstraction-and-learning-with-ru...

Re: The Unison Programming Language

#77

Post by JackMorgan »

iamevn wrote: post #22

it's really neat, I love how easy it is to search for functions by type to find what you need. The one thing I ran into (as someone who only vaguely knows haskell) is that it seems like it's impossible to write a function that takes a list of A or B as an argument and then branch on the type of each element. I can use Either but then I need to decorate each element in the list with Left/Right rather than just use the…

Perhaps are you looking for Sum Types?[0] They let you group several types into a unifying type, e.g. a Shape is a Circle, Square, or Triangle, then you can use pattern matching to have different behavior for each. This example is in F# [1] but it's almost exactly the same as it would be in Haskell.

[0]https://www.schoolofhaskell.com/user/Gabriel439/sum-types [1]http://deliberate-software.com/christmas-f-number-polymorphi...

Re: The Unison Programming Language

#78

Post by Nullabillity »

umvi wrote: post #69
andi999 wrote: post #37

Earlier quoted context omitted.

Cool, but why/what for?

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.

Re: The Unison Programming Language

#79

Post by slver »

lamontcg wrote: post #56
torginus wrote: post #51

Earlier quoted context omitted.

You are right - but choosing the correct solution imho needs to be done with human oversight - I think a semver based dependency resolution works great here, for example if bar requires foo 1.0 and baz needs 1.0.1 they will happily use the same version, but if baz used foo 1.1 they would use the separate ones.

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.

Re: The Unison Programming Language

#80

Post by adrusi »

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…

FWIW because of how unison works, you get a lot of the benefits of version control without using any proper version control. Probably for small, single dev projects version control would just be redundant.

That's not to say this isn't a limitation the project will need to overcome to be useful, just a caveat.

Post reply on HN