Live data from Hacker News

The Unison language

unisonweb.org

121–130 of 144 posts

Re: The Unison language

#121
post #61

Earlier quoted context omitted.

TBH if you're creating a new language after 2014 you should be thinking about how to get good syntax highlighting and other tooling from the language definition itself, because you're competing with a ton of mature languages that had to do this manually through a ton of effort of their communities.

How do you get it from the language definition? By adding metadata to it?

It can be (kinda) done if your language has a parsing grammar.

It doesn't work in practice, since most languages eventually discard parser generators for custom parsing, and good tooling like syntax highlighters don't rely on the literal grammar but something close enough to the grammar to work and still be useful for programmers.

Classic example is you don't want your parser to be strictly defined and fail at any error. You want it to handle errors gracefully and detect almost correct syntax.

Having written some textmate grammars for syntax highlighting I think the post is ridiculous. I'd be terrified to generate that json from the parser, since a bit of thought and experimentation has to go into getting a good syntax highlighter that works with external tooling.

As well I think an LSP implementation is really important, but writing that in your language or generating it from the compiler is a monumental task for a young language and a terrible idea.

Re: The Unison language

#122
> A friendly programming language from the future.

I loathe marketing BS like this. No, you’re not from the future, you pretentious twats.

If you have a good idea, let it stand on its own merit, don’t dress it up with manipulative language.

Re: The Unison language

#123

Earlier quoted context omitted.

No worries. I guess it sounded a bit antagonistic, I apologize for that. I am actually interested in the idea, I was just a little frustrated that it was hard to figure out what was different about the language.

It just sounded honest. ¯\_(ツ)_/¯ It's mainly just an issue of manpower on our end (we do accept doc contributions, but probably we should be doing it); having fresh reader eyes on it like this is still valuable though.

> It's mainly just an issue of manpower on our end (we do accept doc contributions, but probably we should be doing it); having fresh reader eyes on it like this is still valuable though.

That's absolutely fair, and tbh probably the problem. I've probably been thinking about the concept for so long that it doesn't occur to you that the phrase wasn't that well known.

I remember a multi-year project in college I was trying to explain about, and blew right through "potential energy surface" and lost him completely. I didn't realize it was something I'd have to explain.

Re: The Unison language

#125
post #69

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!

My small understanding is that the "(or any other)" part is not correct in your statement, and that you are locked into thinking of version control as being git-like. I think the implication is that version control is not git like, and that it's not that we both changed the text on line 17, rather we both made additions to the underlying structure. Indeed, it's impossible for us to both edit the same file, because fi…

But git works the same way. All files are immutable. All directory trees are immutable. Basically all version control works that way at some level.

Storing data this way doesn't solve the problem of merging the two changes into a new single change. When you can't do that automatically, it's called a conflict.

The only mutable data in git is the list of hashes you've given names to. You can use git without branch names if you want, living in a world of pure immutable hashes. It doesn't do anything to help you get rid of merge conflicts.

Re: The Unison language

#126

Earlier quoted context omitted.

> Yes, philosophically there is a conflict, which is resolved by you deciding which main() function you find more useful. it's not just philosophical though. In git terms, when merging the two sets of changes, someone has to choose which of these functions goes onto the master branch. git calls this a "merge conflict".

No changes are ever made to an existing file, so there are never any merge conflicts. All changes result in a new object/file, named based on a content hash. So in git terms, there are never any updates, only additions, and therefore never any merge conflicts.

Git doesn't store updates or additions. It only stores new objects/files, named based on a content hash.

When the git interface shows you 'updates', it's just looking at the contents of different commits and guessing how the files are related. It's not part of the git data model. You could apply the exact same processing to Unison commits.

So the systems work the same way. They make a new object/file based on parent objects. And when it can't create that new object/file automatically, that's called a "conflict".

Re: The Unison language

#127
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'm guessing language purity is important when it comes to this. Translating the "unison way" to an imperative world of statefulness and random side effects could be rough.

Re: The Unison language

#128

Append only is nice, but I would think a "Garbage Collect" would be useful. Remove all the code not attached to the import tree anymore. Otherwise you will just keep collecting junk forever Honestly git has the problem too, but I expect orphaned/dead code will happen a lot more with this approach.

I suppose you could do it for the top level application code, but all past definitions of libraries must remain. That's the thing that allows safe updates of shared dependencies.

Re: The Unison language

#129
post #49
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 tried something like that in 2016 with Javascript. I parsed the source code and put every AST node on IPFS and linked it to the other node using the hashes. The problem was that this is a _lot_ of overhead...

Spent a year doing R&D into storing a "abstract syntax DAG" consisting of extremely rich syntax nodes (effectively entire programs/modules). That overhead you mentioned is why we decided that failure was a good result.

Re: The Unison language

#130
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'm guessing language purity is important when it comes to this. Translating the "unison way" to an imperative world of statefulness and random side effects could be rough.

You don't need it down to each function. Just having hashes this on the #include/import level of the source code would be a win for optimizing build and test of big code bases. Most build systems today just operate on file time stamps which has a lot of tricky cases where the build system gets out of sync and requires a make clean to get back into decent shape.
Post reply on HN