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

21–30 of 134 posts

Re: The Unison Programming Language

#21

Post by lisper »

ucarion wrote: post #19
lisper wrote: post #14

Earlier quoted context omitted.

No, now I can just redefine the buggy function and all the callers will get the new version automatically. Having to update all callers seems like a high price to pay. Seems like the Right Answer is something like a hash of the api or the contract rather than the implementation.

The (public) name of the implementation is the unique identifier of the contract in most systems, so I think your "Right Answer" is roughly the status quo?

No. The name of a function in current languages has no connection at all to what the function does. (What would be the contract for a function named ‘foo’?)

Re: The Unison Programming Language

#22

Post by iamevn »

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 their types.

This is probably just not how things work in Haskell and I just need to be okay with that.

Re: The Unison Programming Language

#23

Post by 0_gravitas »

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!

Re: The Unison Programming Language

#24

Post by PaulDavisThe1st »

janjones wrote: post #8

There is nice blog post summing up what's cool about Unison[1] [1] https://jaredforsyth.com/posts/whats-cool-about-unison/

Good explanations, but I'm always a little suspicious when I see things like this:

> Code is stored as a structured, type-checked tree in a database, not as text in files

What does everyone think a filesystem is?

Re: The Unison Programming Language

#25

Post by umvi »

lisper wrote: post #12
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…

Sounds like a cool idea, but how do you fix bugs in functions with lots of callers?

That's basically what the twitter thread I linked explains. It sounds like there is an automatic propagation mechanism for updating downstream callers if the type hasn't changed, otherwise it sounds like a manual update process.

Re: The Unison Programming Language

#26

Post by ajuc »

ucarion wrote: post #19
lisper wrote: post #14

Earlier quoted context omitted.

No, now I can just redefine the buggy function and all the callers will get the new version automatically. Having to update all callers seems like a high price to pay. Seems like the Right Answer is something like a hash of the api or the contract rather than the implementation.

The (public) name of the implementation is the unique identifier of the contract in most systems, so I think your "Right Answer" is roughly the status quo?

Nope, according to https://twitter.com/unisonweb/status/1173942969726054401

when you change a function implementation the system has to walk the callers graph backwards starting from all the places where the function was called updating all the implementations with the new hash, then callers of these with the new implementation and so on up to main (or whatever it's called).

I had a chance to implement something like this in a system that used jbpm 3 graph language (basically process X version 1 called process Y version 1 and I updated process Y to version 2). It's nontrivial especially with recursion, I'm wondering how they are dealing with that.

Re: The Unison Programming Language

#27

Post by creata »

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…

> This is probably just not how things work in Haskell and I just need to be okay with that.

Yep, that's just how things work in Haskell: disjoint unions are much simpler regular unions, and they're usually what you want in the first place. I think it'd be nice if Haskell had automatic conversions between types (so a and b can be turned into Either a b implicitly, with an error if a = b) but I don't think there are any plans for that.

Re: The Unison Programming Language

#30

Post by thethimble »

PaulDavisThe1st wrote: post #24
janjones wrote: post #8

There is nice blog post summing up what's cool about Unison[1] [1] https://jaredforsyth.com/posts/whats-cool-about-unison/

Good explanations, but I'm always a little suspicious when I see things like this: > Code is stored as a structured, type-checked tree in a database, not as text in files What does everyone think a filesystem is?

There’s an important distinction between how non-unison code is stored (literally as plain text files which must be re-parsed and re-compiled every time) vs how unison code is stored (as a post-parsing data structure).

The file system is in an entirely different and irrelevant layer of abstraction.

Post reply on HN