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

61–70 of 144 posts

Re: The Unison language

#61

Post by xixixao »

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…

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.

Re: The Unison language

#62

Post by vidarh »

hobofan wrote: post #22
forgotmypwd123 wrote: post #12

The name is already pretty taken.... https://en.wikipedia.org/wiki/Unison_(disambiguation)

That list looks like its very available to me? The only overlap with software are two unmaintained projects.

It's incomplete. There's at least the Unison file synchronizer as well:

https://www.cis.upenn.edu/~bcpierce/unison/

Re: The Unison language

#63

Post by elcomet »

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.

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.

Re: The Unison language

#64

Post by ivanbakel »

thesuperbigfrog wrote: post #39
ivanbakel wrote: post #3

Reading the tour[1], I got the impression of being struck by something not that surprising, but still fundamentally groundbreaking. Beyond just the idea of a global program store (which I hope has space for some virtualenv equivalent), the cleverness of effect handlers as a first-class language feature is very exciting. Once the type system is more mature, this could easily be the next kind of Haskell - a language wh…

Unison seems to combine ideas from Forth, Haskell, and Clojure's Datomic and stir them together into an interesting mix: Forth ideas: a global dictionary with pre-existing and user-definable words Haskell ideas: functional programming and type signatures of functions / words Clojure Datomic ideas: immutable store of object definitions that append and use references to point to the latest definitions. I am curious how…

If you look at the other reply to my comment, someone has linked the Unison docs on their effect handlers implementation - which is what is used for IO, and with any luck, error handling as well. Haskell has several packages for effect handlers, and they're taking off in programming and category theory circles as alternatives to monads for IO.

The short summary is that you can write code with side-effects that you don't define the implementation for, and then let call sites handle those effects or defer them.

Re: The Unison language

#65

Post by pwinnski »

xwowsersx wrote: post #45
nadam wrote: post #13

Earlier quoted context omitted.

Hmmm, interesting. It is getting a bit philosophical: you can view it as a conflict. But you can also view it as: hm we have these nice 2 main functions. Let's create a merged one. Kind of what was previously conflict resolution becomes part of regular programming... A slight perspective change.

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.

Re: The Unison language

#66

Post by pwinnski »

SideburnsOfDoom wrote: post #42
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…

> 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.

Re: The Unison language

#67

Post by m712 »

No mention of Smalltalk in the comments? The "codebase" that is managed by ucm sounds very similar to Smalltalk images. I am personally delighted about this.

Re: The Unison language

#68

Post by cttet »

neurobashing wrote: post #53
dudul wrote: post #46

Earlier quoted context omitted.

How can you tell the elegance or gotchas from a 6 line Hello World?

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.

Re: The Unison language

#69

Post by SamBam »

xwowsersx wrote: post #45
nadam wrote: post #13

Earlier quoted context omitted.

Hmmm, interesting. It is getting a bit philosophical: you can view it as a conflict. But you can also view it as: hm we have these nice 2 main functions. Let's create a merged one. Kind of what was previously conflict resolution becomes part of regular programming... A slight perspective change.

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 files are never modified. They are immutable, like a blockchain transaction.

I haven't quite understood how it works in practice, though, but definitely don't think "git".

Post reply on HN