> A friendly programming language from the future.
It looks like a programming language from the present at best. A programming language from the future would have finally broken free from the prison of plain text.
The Unison Programming Language
91–100 of 134 posts
Re: The Unison Programming Language
#92I'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...
ah yes exactly!
Re: The Unison Programming Language
#93> A friendly programming language from the future. It looks like a programming language from the present at best. A programming language from the future would have finally broken free from the prison of plain text.
Look a little closer. This is not a graphical programming language, but it's definitely not "plain text" either.
Re: The Unison Programming Language
#94I 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 is an uneasy compromise at best. Rich Hickey has a nice talk that digs into the principles around changing software. Once you see this POV, you are unlikely to view Semantic Versioning as anything other than a messy hack.
I'm not saying it is worse than nothing, but sometimes ideas have a way of sticking around too long and making people comfortable.
Re: The Unison Programming Language
#95This looks very cool! Content addressed storage is an incredibly powerful concept, and weaving it into a programming language is a compelling idea.
Question for the devs: How does one deploy Unison code? After my first glance through the docs I don't have a clear picture.
Re: The Unison Programming Language
#96This looks like a neat idea—I can see upsides and downsides, but would have to experiment to see if one outweighs the other. One thing I didn't see in my (admittedly quick) perusal of the tutorial and faq: what is the technique to run a Unison program from the command line? Is it practical for making unix cli tools (yet)?
For the moment, you have to create a function with the appropriate IO ability, and execute using the `run` command from inside the codebase manager. I don't think there's a way to create a standalone executable just yet.
Re: The Unison Programming Language
#97it'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…
If you could give a concrete example of a problem to be solved, I could try to convince you that the method using Either won't actually be all that unwieldy.
Re: The Unison Programming Language
#98Earlier quoted context omitted.
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/ where you can look at the base library, and some (contributed?) libraries as well.
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…
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
[1]: https://www.unisonweb.org/docs/tour#unisons-interactive-scra...
Re: The Unison Programming Language
#99Earlier 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…
I think Unison paired with a strong graph database instead of the filesystem would be a powerful combo. It would very naturally represent the AST graph directly and would benefit from graph db optimizations. The cost would be the need to invest a lot in new tooling: you'd want a graph db-based source control implementation that offers similar cryptographic certainty to git; you'd have trouble using existing tooling d…
The combination of the two makes me think auto/AI-generated code would be much more feasible and powerful in such an ecosystem.
Re: The Unison Programming Language
#100what can you build with it?