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 Unison Programming Language
11–20 of 134 posts
Re: The Unison Programming Language
#12I 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?
Re: The Unison Programming Language
#13I 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?
The same way we do now: release a new version and tell people to migrate.
Re: The Unison Programming Language
#14Earlier quoted context omitted.
Sounds like a cool idea, but how do you fix bugs in functions with lots of callers?
The same way we do now: release a new version and tell people to migrate.
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.
Re: The Unison Programming Language
#15I 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…
> identified by a hash of its implementation
Sound a lot like darklang.
Like others, I am dubious about this being in any way a useful feature. Separating implementation from name (/interface) and binding to that interface/name instead of the implementation is one of the fundamental and useful parts of abstraction.
Re: The Unison Programming Language
#16Unison is already the name of a bidirectional files synchronization software (AFAIR developped in OCaml).
Re: The Unison Programming Language
#17This looks pretty well done. It doesn’t seem like a gimmick; they’ve made a lot of good choices beyond the core conceit of content-addressable code. One thing I didn’t see skimming the language reference page: is there any sort of typeclass mechanism?
No, but it’s planned; probably in the form of implicit parameters.
Re: The Unison Programming Language
#18Re: The Unison Programming Language
#19Earlier quoted context omitted.
The same way we do now: release a new version and tell people to migrate.
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?
Re: The Unison Programming Language
#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/