Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unison language

unisonweb.org

Post reply on HN
Print view View original

81–90 of 144 posts

Re: The Unison language

#81

Post by ahel »

giancarlostoro wrote: post #32

One thing that takes away from programming languages is not having code samples on the index. I think this lets someone know immediately if it's interesting to them or not. Show a sample of code with the console output or a screenshot of an UI from the code. I think Racket had it right ages back. They would show everything from a web server, to other things. This is what major programming languages (with some excepti…

have a look if you want some example and what dev process looks like https://dev.to/petets/palindromes-with-unison-5h9o

Re: The Unison language

#82

Post by DerSaidin »

This is cool.

I've wanted to see a Merkle tree based AST for faster incremental compilation (and incremental static analysis).

I wonder if the source manager interface makes this easier to use than editing source files?

AST can still be the source of truth. To edit need to generate source text from AST, edit as text, parse to AST, save.

In other words, I think most of the benefits of this can live behind the scenes for other languages.

Re: The Unison language

#83

Post by scott_s »

blain_the_train wrote: post #34
giancarlostoro wrote: post #32

One thing that takes away from programming languages is not having code samples on the index. I think this lets someone know immediately if it's interesting to them or not. Show a sample of code with the console output or a screenshot of an UI from the code. I think Racket had it right ages back. They would show everything from a web server, to other things. This is what major programming languages (with some excepti…

Small code samples tell me next to nothing. How could they. I want a clear explanation of the foundational aspects.

I don't want small code samples. I want well defined problems that this particular language is well suited for, as demonstrated by a dozen (or a few dozen) line program which uses the core features of the language to elegantly solve that problem. That gives me a feel for what the language is, and if interested, I'll learn about the foundations.

Re: The Unison language

#85

Post by UIZealot »

This is seriously impressive. I've always felt that some kind of database system is needed for code in which you store each function individually. Unison not only has that, it goes one step further to identify a function by its hash. I can't wait to see what the world of programming can become along this direction.

Re: The Unison language

#86

Post by bnjmn »

DerSaidin wrote: post #82

This is cool. I've wanted to see a Merkle tree based AST for faster incremental compilation (and incremental static analysis). I wonder if the source manager interface makes this easier to use than editing source files? AST can still be the source of truth. To edit need to generate source text from AST, edit as text, parse to AST, save. In other words, I think most of the benefits of this can live behind the scenes f…

I don't think you can have a proper Merkle tree if cycles are possible, and cycles definitely are possible in this AST representation: https://www.unisonweb.org/docs/faq#how-does-hashing-work-for...

Re: The Unison language

#87

Post by CarlRJ »

cttet wrote: post #68
neurobashing wrote: post #53

Earlier quoted context omitted.

you can infer a lot; is it LISPy, is it C-ish, or one of the Haskell family, etc. I think you can tell a lot from just which family of syntax.

No, take Reason as an example: it is basically Ocaml. Despite having a C-like syntax, it is quite different from it. The syntax barrier is usually much smaller than the language itself.

And yet... someone trying to “sell” me a language while seemingly refusing to show me any code samples feels like someone trying to sell me a car based entirely on a spec sheet with no pictures and without actually seeing, touching or experiencing the car. They both provoke a reaction of suspicion - “what are they trying to hide?” As if they don’t trust me, the customer, to be able to understand the very thing they want/expect me to buy.

I’m perfectly fine with a page that says, “here’s a code sample - notice that it looks similar to C, but here’s a list of reasons / an explanation of why/how it’s actually quite different from C.”

One of my favorite programming books of all time is K&R, from back before ANSI, even. It said, “here’s a simple problem to solve, and here’s how you solve it in our language.” Repeatedly. Explaining how the features helped to solve the problem at hand. It was revelatory. And it assumed its audience to be knowledgeable programmers. It didn’t spend the first chapter just describing all the features or how great the language is without showing any code.

Re: The Unison language

#88

Post by dunham »

ktpsns wrote: post #58
Tade0 wrote: post #44

Earlier quoted context omitted.

Perhaps this is the reason: https://www.unisonweb.org/docs/language-reference#a-note-on-...

Interesting. Maybe they should add further representations of the code. This is not the only language where there are mutliple representations of the same "code". Wolfram Mathematica (or "the Wolfram language") introduced "forms" for that, for instance https://reference.wolfram.com/language/ref/FullForm.html or https://reference.wolfram.com/language/ref/InputForm.html or, quite charming in the math context, https://r…

Also Bucklescript and ReasonML respectively provide OCaml and javascript-like syntax over the same AST and can translate your code between the two (as seen in the try reasonML UI).

Re: The Unison language

#89

Post by zubairq »

nadam wrote: post #43

I find the content-addressed, name-independent, immutable (kind of blockchainy) approach to source code very interesting. On the other hand this seems to be rather orthogonal to other (semantic) aspects of the language. I wonder what would happen if we would change one thing at a time to test the idea: create something like unison based on an existing popular programming language. (python, javascript, java, etc...) A…

I have done exactly that with a language called Pilot. It is not pure JS but based on JavaScript and all code is content addressable and indexed by the sha256 of the code

Re: The Unison language

#90

Post by the_duke »

pwinnski wrote: post #65
xwowsersx wrote: post #45

Earlier quoted context omitted.

There's nothing philosophical about it! There will exist a conflict as far as Git (or any other) version control system is concerned. That's all he saying!

That seems to be incorrect. The linked page seems to suggest that both changes will exist without any conflict at the VCS level at all.

That's like saying Git has no conflicts because a file can have different contents in different commits.

A conflict can only arise when trying to unify (aka merge) two different states. The difference is the representation, with Git (naively explained) mapping file paths to text blobs , and Unison mapping identifiers to AST nodes.

Post reply on HN