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

71–80 of 144 posts

Re: The Unison language

#71

Post by zawodnaya »

the_duke wrote: post #11
nadam wrote: post #10

Earlier quoted context omitted.

" I make the green 'OK' button now red, and you make it blue" I did not fully read the introduction yet, but in my mind, in a truly content-addressed system this is not a conflict: you have the hash of a main() function which ultimately makes the button red, and the other guy has a main() function that makes the button blue. No conflict in the physical sense. Yes, philosophycally there is a conflict, which is resolve…

Of course there are still conflicts everywhere. Developer A makes the button red, developer B changes the label from "OK" to "Accept", both inside the same function. You can't just pick one or the other, you have to combine the changes. Or two developers add two different fields to a type. Or ... Sadly the docs only have placeholders for "Concurrent work and resolving edit conflicts" and "Pull requests and collaborat…

This is the right idea. Conceptually there are conflicts which get resolved in the Unison tooling, but you will never get Git conflicts.

Re: The Unison language

#72

Post by SamBam »

blamestross wrote: post #24

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.

Git has this problem only as far as the developer's storage of the history of all files is concerned. That "junk" doesn't remain in the final program.

You can have a decades-old git repository containing hundreds of MBs of files, but output a 2kB program. Someone correct me, but it sounds like if you had the same thing with a unison project, the actual executable size can only grow?

Re: The Unison language

#73

Post by SideburnsOfDoom »

pwinnski wrote: post #66
SideburnsOfDoom wrote: post #42

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.

Ok, if you want to be pedantic, lets be pedantic:

> No changes are ever made to an existing file,

I did not say or imply that there were. it's a new version, of course.

> so there are never any merge conflicts

Does not follow. There is only one HEAD (latest version) of foo.txt on the master branch. In a merge, it has two (or more) parent objects (1).

> All changes result in a new object/file ... therefore never any merge conflicts.

And yet somehow git calls the process of deciding what's in this new (version of the) file with two parents "resolving a merge conflict". Because the two parent changes can't be automatically reconciled. They are in conflict.

1) https://softwareengineering.stackexchange.com/questions/3142...

Re: The Unison language

#74

Post by antisthenes »

elcomet wrote: post #63
vidarh wrote: post #59

Earlier quoted context omitted.

Syntax stops me from even considering some languages, because to a lot of us it is important. I spend most of working hours reading code; as a result how easy it is to read is important not just for my productivity, but for my overall happiness in life. A small sample on the front page will not tell me if a language is good enough, but it can give me an idea if it's worth spending more time reading up on it or not.

Syntax is something you become used to in a few hours. But it's not what's the most important and will make your time more efficient in the end.

> Syntax is something you become used to in a few hours.

This is completely subjective and not at all universal.

Re: The Unison language

#75

Post by setr »

vidarh wrote: post #59
tobr wrote: post #50

Earlier quoted context omitted.

Syntax is easy to show, but ultimately rather unimportant. If the big idea of a language is something substantial, starting by showing the syntax arguably just creates a distraction.

Syntax stops me from even considering some languages, because to a lot of us it is important. I spend most of working hours reading code; as a result how easy it is to read is important not just for my productivity, but for my overall happiness in life. A small sample on the front page will not tell me if a language is good enough, but it can give me an idea if it's worth spending more time reading up on it or not.

The problem is that readability is largely a matter of naming conventions, organization, and adherence to known patterns. The language becomes more readable as you use it. Anything that isn't a C derivative is unreadable if you only know C.

There are of course actual blockers to readability, like usage of similar-looking sigils and poor system library naming, but otherwise the syntax really doesn't tell you any useful information. It's the semantics that tell you how it'll all fall apart

Re: The Unison language

#76

Post by vidarh »

elcomet wrote: post #63
vidarh wrote: post #59

Earlier quoted context omitted.

Syntax stops me from even considering some languages, because to a lot of us it is important. I spend most of working hours reading code; as a result how easy it is to read is important not just for my productivity, but for my overall happiness in life. A small sample on the front page will not tell me if a language is good enough, but it can give me an idea if it's worth spending more time reading up on it or not.

Syntax is something you become used to in a few hours. But it's not what's the most important and will make your time more efficient in the end.

Maybe you do. I don't. Syntax is something that has a substantial impact on how I think and work. Presentation overall matters immensely.

Re: The Unison language

#77

Post by colonwqbang »

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.

Then how do you know which main function to use? That information has to be stored somewhere. Or does the user provide the hash for the main function they wish to run?

Re: The Unison language

#78

Post by robofanatic »

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.

Little code snippets are nice to get a quick feel of the language. A good "Get Started" page is also a must have. I love languages or frameworks that have a step by step clear instructions on how to get started.

It's almost like taking test drives when you go car shopping. You don't want to open the hood and check what's inside right away you just want to be able to drive the car.

Re: The Unison language

#79

Post by nlh »

refried_ wrote: post #31
jedimastert wrote: post #9

Maybe I've been out of the game or something. But I don't think saying everything is "content-addressed" can land as such of a big mic-drop moment when I've never heard the term or the concept in my life and the front page does absolutely nothing to explain it beyond that. ------ EDIT: My tone here is a little more antagonistic that I meant (proofread kids, don't just check for spelling and publish) but my first impr…

Hey; Unison author here— Definitely appreciate this honest and helpful, specific docs feedback, so thanks for taking the time to put it together. We do want the value of Unison to be straightforward given even a quick skim of the site, so: sorry about the current state, we'll try to improve it. :)

Just to add to that - I’m kind of in the same boat here. I had to read the homepage and intro sections a few times and I’m honestly still a bit lost in understanding who this benefits and why.

Just by way of anchoring: I’m no dunce, I’m a typical nerdy guy who knows his UNIX and has written lots of C, Python, JavaScipt, Ruby, etc. Written some mobile apps. Written plenty of web stuff. But I’m not immersed in any academic language study and not really an FP guy.

I don’t think you should dumb this down - the text itself is very good prose. But the context is missing something — perhaps a paragraph or two of anchoring for us “normal programmers” to explain why this is relevant to people who normally write Python web apps or Rust utilities or C++ games all day long (or if it’s not relevant, why, and who it is relevant for).

Good luck with the project!

Re: The Unison language

#80

Post by vidarh »

setr wrote: post #75
vidarh wrote: post #59

Earlier quoted context omitted.

Syntax stops me from even considering some languages, because to a lot of us it is important. I spend most of working hours reading code; as a result how easy it is to read is important not just for my productivity, but for my overall happiness in life. A small sample on the front page will not tell me if a language is good enough, but it can give me an idea if it's worth spending more time reading up on it or not.

The problem is that readability is largely a matter of naming conventions, organization, and adherence to known patterns. The language becomes more readable as you use it. Anything that isn't a C derivative is unreadable if you only know C. There are of course actual blockers to readability, like usage of similar-looking sigils and poor system library naming, but otherwise the syntax really doesn't tell you any usefu…

I couldn't disagree more. Syntax changes whether I can look at a page of code and get an idea of structure and which elements to focus attention on, or whether I need to read everything in detail.

It doesn't matter that much when I have found a piece of code that I need to read and understand every detail of, but that is a tiny proportion of the amount of code reading I do - most of the time reading code is about grasping overall structure to learn a codebase well enough to find the points you need to focus on and read.

A clean syntax makes the difference between always having to read each token vs. being able to speed-read by pattern matching high level structure when you don't need the details of that specific piece of code.

I've worked with dozens of languages, with wildly differing syntax, and I'll say that once you reach a certain base capability-level, syntax matters more to me than semantics.

You can paper over a lot of semantic difference.

I can (and have, and so have many others) build libraries to do object-oriented programming in C, for example, and I have implemented closures in C too [1]. So the reason I don't do much C any more is not semantics, but that there is no mechanism for plugging those semantic gaps that creates readable code.

There are languages where the semantics paints you into a corner and makes plugging the holes too hard, so it's not that semantics doesn't matter at all. But it's usually easier to paper over semantic gaps than unreadable syntax.

[1] http://hokstad.com/how-to-implement-closures

Post reply on HN