Unison: a next-generation programming platform • Hacker News Board

Re: Unison: a next-generation programming platform

#11

Post by mtrimpe » Fri, May 08, 2015, 6:35 PM UTC

I came here to complain about calling things 'next-generation languages' when it's obvious that a next-gen language would have to have a purely functional AST.

Turns out Unison has that; so you've got my interest!

I agree with the other comments though that these (amazing) salient details could be communicated a bit more succinctly ;)

P.S. I have a presentation up at https://speakerdeck.com/mtrimpe/graphel-the-meaning-of-an-im... which lists some of the real-world benefits of such a language... feel free to use it for inspiration.

Re: Unison: a next-generation programming platform

#12

Post by bcg1 » Fri, May 08, 2015, 6:41 PM UTC

On the surface it sounds interesting, but I don't really buy the idea that programming is terribly limited by the quality of text editors. Even "basic" editors like vim and emacs can almost instantly catch most syntax problems, and IDEs like Eclipse and Visual Studio are great about complaining if you make a mistake.

In my experience, these days relatively few problems come from language syntax errors ... most problems come from mistakes in logic, poor systems integration, or incorrect validation of input data. Not sure how Unison will solve those challenges, but to be fair maybe that is out of scope.

However it is hard to slog through the marketing, and in the end its just not clear from the writeup what sort of programs one would write in Unison, so it doesn't really inspire me to spend any more time trying to learn about it.

Re: Unison: a next-generation programming platform

#13

Post by mtrimpe » Fri, May 08, 2015, 6:43 PM UTC

jackmaney wrote: post #2

Pro Tip: if I have to dig through eight paragraphs of fluff to find out what the fuck your product is, then you REALLY need to rethink the description of your product. In particular, it was not at all clear what was meant by a "programming platform". Until I finally stumbled onto the description below, I thought it was just another web-based IDE. > What is the Unison platform? At a high level, it consists of three co…

If I understand it correctly it's like Typed Racket with a purely functional AST which is also a content-addressable Merkle-tree and a UI with paredit-style type correctness.

Re: Unison: a next-generation programming platform

#14

Post by irickt » Fri, May 08, 2015, 6:44 PM UTC

jackmaney wrote: post #2

Pro Tip: if I have to dig through eight paragraphs of fluff to find out what the fuck your product is, then you REALLY need to rethink the description of your product. In particular, it was not at all clear what was meant by a "programming platform". Until I finally stumbled onto the description below, I thought it was just another web-based IDE. > What is the Unison platform? At a high level, it consists of three co…

The author posted a followup to counter the impressions of vaporware: http://unisonweb.org/2015-05-07/update.html

Re: Unison: a next-generation programming platform

#15

Post by vezzy-fnord » Fri, May 08, 2015, 6:46 PM UTC

Unison is also already the name of a file sync program written in OCaml, a team collaboration service, a proprietary newsreader and apparently a security management (access control/intrusion detection/firewall/etc) platform.

The file sync is probably the most popular, and the one that first came to mind.

I realize that the exclusive namespace for software titles is shrinking, but I think that when you already have this much ambiguity, it's not a wise choice to pick generic dictionary word names. Putting some thought into naming things does pay off.

Re: Unison: a next-generation programming platform

#16

Post by vinodkd » Fri, May 08, 2015, 6:51 PM UTC

mtrimpe wrote: post #13

jackmaney wrote: post #2

Pro Tip: if I have to dig through eight paragraphs of fluff to find out what the fuck your product is, then you REALLY need to rethink the description of your product. In particular, it was not at all clear what was meant by a "programming platform". Until I finally stumbled onto the description below, I thought it was just another web-based IDE. > What is the Unison platform? At a high level, it consists of three co…

If I understand it correctly it's like Typed Racket with a purely functional AST which is also a content-addressable Merkle-tree and a UI with paredit-style type correctness.

this was strangely entirely grokkable, thanks.

Re: Unison: a next-generation programming platform

#17

Post by joshstrange » Fri, May 08, 2015, 6:53 PM UTC

> next-generation programming platform

Sounds like a pretty BS claim for what appears to be vaporware (Also the claims they make on their page are pulled out of their ass "Perhaps 70% of developer time is spent dealing with parsing, serialization, and persistence." <- WTF???).

Re: Unison: a next-generation programming platform

#18

Post by breadbox » Fri, May 08, 2015, 6:58 PM UTC

ripter wrote: post #3

> Perhaps 70% of developer time is spent dealing with parsing, serialization, and persistence. Values are encoded to and from JSON, to and from various binary formats, and to and from various persistent data stores… over and over again. This is not my experience at all. I've spent maybe an hour or two in the last few months on parsing, serialization, and persistence. For the work I do, these are all solved problems.…

Indeed. I think this is the key takeaway from that whole passage:

> These numbers are made up, of course

Re: Unison: a next-generation programming platform

#19

Post by pjc50 » Fri, May 08, 2015, 7:00 PM UTC

Link is currently unresponsive, but I think this came up on HN before - and had a similar flavour to TempleOS, in that it may be brilliant but is unlikely to ever make sense to anyone but the author.

Re: Unison: a next-generation programming platform

#20

Post by mercurial » Fri, May 08, 2015, 7:03 PM UTC

jackmaney wrote: post #7

ripter wrote: post #3

> Perhaps 70% of developer time is spent dealing with parsing, serialization, and persistence. Values are encoded to and from JSON, to and from various binary formats, and to and from various persistent data stores… over and over again. This is not my experience at all. I've spent maybe an hour or two in the last few months on parsing, serialization, and persistence. For the work I do, these are all solved problems.…

>> Perhaps 70% of developer time is spent dealing with parsing, serialization, and persistence. Values are encoded to and from JSON, to and from various binary formats, and to and from various persistent data stores… over and over again. > This is not my experience at all. Yeah, unless you're tinkering around in a side project just to learn something, don't build your own JSON parser or writer. I've spent WAY more ti…

If you're doing low-level anything, it's usually because you're interested in the "exhaustive detail". This is quite confusing.

> Also as a result, Unison has a simple story for serialization and sharing of arbitrary terms, including functions. Two Unison nodes may freely exchange data and functions—when sending a value, each states the set of hashes that value depends on, and the receiving node requests transmission of any hashes it doesn’t already know about. Using nameless, content-based hashes for references sidesteps complexities that arise due to the possibility that sender and receiver may each have different notions of what a particular symbol means (because they have different versions of some libraries, say).

Yeah, I can see how this is going to solve the problem of persistence and networking once and for all. Or not. As for sidestepping the problem of having different versions of the same library on different nodes and serializing data, that's going to work fine until the first rename, or when node A with version 1 of the library sends a data structure with half the fields understood by version 2 of the library on node B...