6 ms·

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 Githu

by dthul 5y ago

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 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 code into a scratch file, editing it and pushing it back into Unison's database sounds kind of annoying. Again, this could probably be solved with an editor that would make this process more seamless and feel more like editing regular code. As it currently stands it seems very cumbersome to use, mostly due to the tedious process of even just exploring a codebase, nevermind modifying it.

zawodnaya 5y ago
In practice it's a lot less annoying than navigating a file hierarchy and looking in text files that have a lot of things other than what you're looking for. See also https://share.unison-lang.org/ https://share.unison-lang.org/ where you can look at the base library, and some (contributed?) libraries as well.
- dthul 5y ago
  I agree that text files might not be the best way to store code. My point was more that all of the existing tools like code editors and version control systems have been designed around the concept of files though. And instead of Unison being able to tap into the existing ecosystem of tooling, they have to rebuild custom versions. Maybe there would be a way to map a Unison codebase onto the file system and back? Edit: also worth mentioning that thanks to specialized editors you don't need to manually browse through files but you can browse your code similarly to https://share.unison-lang.org https://share.unison-lang.org if you so please. That's another plus point of the vast existing ecosystem, it already offers so much and it's a shame that Unison can't make use of it (at least for the moment).
  - maddyboo 5y ago
    After reading through the Unison tour [0] with an open mind, I actually think it makes excellent use of existing tools through its "scratch files" approach [1]. The gist of it is that you can check out sections of code that you want to work on as a plain text file and you can do whatever you’d do with a text file: open it in your editor, syntax highlighting, copy/paste, whatever floats your boat. The cool part is that the “Unison codebase manager” (ucm) watches the scratch files and re-parses them whenever a file changes. I presume any syntax or type errors will be immediately shown in the ucm output. Cool, you say, but we can already do that with file watchers like `entr` and traditional languages, so why should I care? Well, it goes further. You can start a line with a > character followed by an expression and the expression will be evaluated when you save the file, printing the output inside of ucm. It’s basically a REPL that you control from your editor. Cooler still, building on this concept is the `test>` prefix which, you guessed it, creates a unit test and runs it inside ucm, showing you whether it passed or not. And as a consequence of Unison’s content-addressable nature, after a test has run for a given expression’s content hash, the result is cached and the test doesn’t need to be re-run unless the hash changes (impure functions are soooo 2020). After you’re done with the scratch file, you can run `add` in ucm to add either certain parts (I think) or all of the work you’ve done in the scratch file to the source codebase, and this includes the tests that you wrote along with their cached values (I think)! I personally find this workflow to be very compelling. To me, this approach is much akin to the source control that we do today, but it's actually aware of the context and meaning of the changes. Git, on the other hand, relies on weak heuristics to figure out what changed between versions of text-based files. I am very happy to see projects that push beyond the boundaries of the paradigms we’ve been stuck in for the past 60+ years. I also find it quite funny that Hacker News, a forum centered around startups, can often be so conservative when it comes to new technologies. [0]: https://www.unisonweb.org/docs/tour https://www.unisonweb.org/docs/tour [1]: https://www.unisonweb.org/docs/tour#unisons-interactive-scratch-files https://www.unisonweb.org/docs/tour#unisons-interactive-scra...
brundolf 5y ago
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.
- adrusi 5y ago
  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.
imtringued 5y ago
No, they just need to use FUSE and provide file system level access to the source code.
- dthul 5y ago
  Yes, I thought about something like that. Being able to map it to the filesystem and back to the Unison database. But then, what is the point of this content addressed code again? What do we gain from it that we don't already have now? With current file based version control you already have an append only repository, code is never deleted from the .git directory, it's just not always mapped to a file in the source code directory (until you check out an old revision, that is). Edit: I guess Unison still has the unique feature that dependencies are referred to by identity and not name.
adrusi 5y ago
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.

by dthul 5y ago

zawodnaya 5y ago

In practice it's a lot less annoying than navigating a file hierarchy and looking in text files that have a lot of things other than what you're looking for. See also https://share.unison-lang.org/ https://share.unison-lang.org/ where you can look at the base library, and some (contributed?) libraries as well.

dthul 5y ago
I agree that text files might not be the best way to store code. My point was more that all of the existing tools like code editors and version control systems have been designed around the concept of files though. And instead of Unison being able to tap into the existing ecosystem of tooling, they have to rebuild custom versions. Maybe there would be a way to map a Unison codebase onto the file system and back? Edit: also worth mentioning that thanks to specialized editors you don't need to manually browse through files but you can browse your code similarly to https://share.unison-lang.org https://share.unison-lang.org if you so please. That's another plus point of the vast existing ecosystem, it already offers so much and it's a shame that Unison can't make use of it (at least for the moment).
- maddyboo 5y ago
  After reading through the Unison tour [0] with an open mind, I actually think it makes excellent use of existing tools through its "scratch files" approach [1]. The gist of it is that you can check out sections of code that you want to work on as a plain text file and you can do whatever you’d do with a text file: open it in your editor, syntax highlighting, copy/paste, whatever floats your boat. The cool part is that the “Unison codebase manager” (ucm) watches the scratch files and re-parses them whenever a file changes. I presume any syntax or type errors will be immediately shown in the ucm output. Cool, you say, but we can already do that with file watchers like `entr` and traditional languages, so why should I care? Well, it goes further. You can start a line with a > character followed by an expression and the expression will be evaluated when you save the file, printing the output inside of ucm. It’s basically a REPL that you control from your editor. Cooler still, building on this concept is the `test>` prefix which, you guessed it, creates a unit test and runs it inside ucm, showing you whether it passed or not. And as a consequence of Unison’s content-addressable nature, after a test has run for a given expression’s content hash, the result is cached and the test doesn’t need to be re-run unless the hash changes (impure functions are soooo 2020). After you’re done with the scratch file, you can run `add` in ucm to add either certain parts (I think) or all of the work you’ve done in the scratch file to the source codebase, and this includes the tests that you wrote along with their cached values (I think)! I personally find this workflow to be very compelling. To me, this approach is much akin to the source control that we do today, but it's actually aware of the context and meaning of the changes. Git, on the other hand, relies on weak heuristics to figure out what changed between versions of text-based files. I am very happy to see projects that push beyond the boundaries of the paradigms we’ve been stuck in for the past 60+ years. I also find it quite funny that Hacker News, a forum centered around startups, can often be so conservative when it comes to new technologies. [0]: https://www.unisonweb.org/docs/tour https://www.unisonweb.org/docs/tour [1]: https://www.unisonweb.org/docs/tour#unisons-interactive-scratch-files https://www.unisonweb.org/docs/tour#unisons-interactive-scra...

brundolf 5y ago

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.

adrusi 5y ago
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.

imtringued 5y ago

No, they just need to use FUSE and provide file system level access to the source code.

dthul 5y ago
Yes, I thought about something like that. Being able to map it to the filesystem and back to the Unison database. But then, what is the point of this content addressed code again? What do we gain from it that we don't already have now? With current file based version control you already have an append only repository, code is never deleted from the .git directory, it's just not always mapped to a file in the source code directory (until you check out an old revision, that is). Edit: I guess Unison still has the unique feature that dependencies are referred to by identity and not name.

adrusi 5y ago

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.