
Unison: a next-generation programming platform - adamwk
http://unisonweb.org/2015-05-07/about.html
======
pchiusano
Wow, author here, was not expecting this to end up here! This project is very
much in development, it's not close to a finished product and I hope I didn't
give that impression. I created the site so there'd be a space other than my
blog to share updates about progress and so on. If everything I wrote sounds
like nonsense, check back in 6 months. I am hoping things will be much further
along, and more concrete by then. It will get there.

I definitely appreciate the feedback from folks about how it is unclear what
the project even is from the descriptions. I am still trying to figure out the
best way to explain it succinctly (so far haven't been too successful). Having
a better demo to show would definitely go a long way.

This might help a little bit - here's a video and some explanation of the
expression editor from my blog: [http://pchiusano.github.io/2015-03-17/unison-
update5.html](http://pchiusano.github.io/2015-03-17/unison-update5.html) The
platform is going to be more than just the editor, but that might provide a
feel for what the editing experience could be like. Obviously many details and
polish to be worked out.

~~~
jimfleming
Ok, so I spent about an hour casually reading the posts, watching the demo
videos and glancing at the code. I agree with your premise and I like a lot of
the implementation so far. It's great to see more innovation and research in
this area alongside Light Table, Eve (which seems to be going in a similar
direction with spreadsheets), NoFlo and others.

I'm curious about the goals of the project. If the goal is to replace an
existing language and editor pairing then it's going to be an uphill battle
(see previously mentioned related projects). If it's to be supplemental with
existing development tools then what use cases are you targeting?

Adding this as an optional layer to an existing editor might help work out
some of the ergonomics. Performance issues aside, building on top of Atom
might be a good choice since it's mostly web based like the current UI in the
demos. Similarly, a custom kernel or cell type in ipython might get the ideas
into daily use.

~~~
thenomad
Where are the demo videos? Couldn't find those and I'd be very interested to
see them.

~~~
jimfleming
Here's the most recent video that I could find:
[http://pchiusano.github.io/2015-03-17/unison-
update5.html](http://pchiusano.github.io/2015-03-17/unison-update5.html)

A few of the other posts have videos too:
[http://pchiusano.github.io/unison/](http://pchiusano.github.io/unison/)

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

> Another 25% is spent on explicit networking. We don’t merely specify that a
> value must be sent from one node to another, we also specify how in
> exhaustive detail.

Honestly I'm not sure what the author means by this. If I have a value others
might want to know about, I just trigger an event. There is no "exhaustive
detail' going on. (Plus events are easy to grep).

>Somewhere in between all this plumbing code is a tiny amount of interesting,
pure computation, which takes up the remaining 5% of developer time. And
there’s very little reuse of that 5% across applications, because every app is
wrapped in a different 95% of cruft and the useful logic is often difficult to
separate!

Boiler plate code used to be an issue, but the languages I still use have ways
around it. (macros, first class functions, extending, etc). We build modules
and libraries and controls, all reusable code that lets me spend most of my
time being bored in meetings.

~~~
jackmaney
>> 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 time thinking about how to structure my data for
serialization than how to serialize it. For the vast majority of use cases,
serialization is such a solved problem that if there isn't an obvious way to
proceed, you're probably doing it wrong.

>> Another 25% is spent on explicit networking. We don’t merely specify that a
value must be sent from one node to another, we also specify how in exhaustive
detail.

> Honestly I'm not sure what the author means by this.

Doing low-level socket programming? Maybe? But in the grand scheme of things,
that's probably a fairly specialized use case.

~~~
hyperpallium
Maybe the author started this project some years ago, before parsing and
network libraries were common? Because if you don't have libraries, he's
right.

Starting from scratch _can_ yield radically better solutions than how
tech/market happened to evolve.

~~~
nkassis
It would have to be extremely old for that to be true. All the problems he
mentioned have had some form of solution for decades. Some uses cases needed
significant changes in those solutions (ex: need for NoSQL DBs) but most
development have stayed in a zone where the available patterns existed for the
things he mentioned.

~~~
hyperpallium
hmm, JSON is only a decade and a half old, so not "decades" for that
particular one. And it's only really taken off within the last few years.

You're right about it being _conceptually_ solved for many decades, but we
here developers like to reinvent everything every decade or so.

For example, back when XML was gaining in popularity, around 2000, there were
new parsers/serializing libraries launched all over the place - even standards
like SAX and DOM. Many people rolled their own; many had to.

~~~
groby_b
It's not like JSON is the first serialization format ever. (I __still __have
XDR & CDR nightmares, and that was the early 90's)

So, yes, decades. Not necessarily solved well, but yes, people shipped data
over the network before JS ;)

------
panic
Here are some more blog posts about the project:
[http://pchiusano.github.io/unison/](http://pchiusano.github.io/unison/)

As far as I can tell, the goal is to put interaction with a UI on the same
level as editing a program. To this end, Unison expressions, values and UI
elements all live in a single syntax tree which can be edited in a structured
way.

A demo would go a long way toward making this all clearer. Even some text
describing what it would be like to use the finished product would help.

~~~
waynecochran
Doesn't this go against the MVC grain -- UI / model separation of concerns?

~~~
melloclello
Well, it just means you only have one V and one C for all the Ms in the
universe.

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

~~~
Ericson2314
One of the mantras of functional programming is get your data structure right,
and everything else falls into place. As an experienced functional programmer,
I see this in practice every time I program--even a slightly "wrong" type
pollutes the code dramatically.

The idea then with structure/tree/semantic editors is two-fold.

First, text is obviously the wrong the wrong data structure for programs, so
even if people manage to provide fairly good support with the "modern IDE",
the effort it takes is staggering. And still details like files, character
encodings, god damn tabs vs. spaces, and terminals leak through. One can't
help but wonder how much farther they would get were their efforts directed
more efficiently. Look at this
[https://github.com/yinwang0/ydiff](https://github.com/yinwang0/ydiff) for
example, blows text diff out of the water.

Second the idea is maybe text is the "wrong data structure" for programmers
too, not just tool-smiths. I admit there are bunch more
psychological/neurological aspects that make the answer less obvious. But I
see no reason why not to keep an open mind until a polished tree editor exists
for empirical testing. Even if text is in someways better, the improved
functionality a tree editor offers could offset that dramatically.

~~~
seanmcdirmid
Functional programming kind of screws itself when it comes to "implementing"
modern good IDEs; the aversion to state makes it difficult to implement good
tree-incremental error resistant parsing and type checking that is usable in a
language aware editor.

I've developed plenty of advanced IDE infrastructure; e.g. see

[http://research.microsoft.com/en-
us/people/smcdirm/managedti...](http://research.microsoft.com/en-
us/people/smcdirm/managedtime.aspx) and [http://research.microsoft.com/en-
us/projects/liveprogramming...](http://research.microsoft.com/en-
us/projects/liveprogramming/typography.aspx)

The trick was abondoning FRP-style declarative state abstractions (which was
my previous research topic) and moving onto something that could manage state
in more flexible ways (as we say, by managing times and side effects instead
of avoiding them). And once you nailed the state problem, incremental parsing,
type checking, and rich editing are actually easy problems.

~~~
Ericson2314
Yeah, incremental parsing is quite anti-functional--but tree editors don't
need to parse.

Type checking I am less convinced. With syntax-directed methods one should be
able to hash-n-cache each sub expression and get incremental for free. In the
case of syntax directed + passing hints down the tree, just keep track of the
hints too. [...let's not talk about Damas-Milner. :)]

Then, which I think Unison goes for, there is the approach where one never has
untyped syntax to begin with. Not sure how annoying this is with normal
programming, but should be great for theorem proving, which probably where
tree editors will shine the most anyways.

~~~
seanmcdirmid
Coupled with type inference, which you will need if you use a structured
editor or not, then incremental type checking is indeed very non functional.

~~~
Ericson2314
We agree incremental use of global type inference algorithms is non-function.

But I am also saying you don't need to do that. Certainly don't need type-
inference in the case where the ASTs are typed by construction. And the syntax
directed algorithms can also infer somewhat.

You can also alternatively cache the result of global inference, which sucks
for refactoring but preserves purity.

~~~
seanmcdirmid
You will need type inference if you want any sort of non local
communication...e.g. variables that hold different values or functions. But
ya, if your language is just pure trees with no names or symbol tabkes, you
don't need it; not very useful, however.

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

~~~
MrBra
It was also the name of a popular general midi soundfont :)

~~~
chippy
And it's also the name of the second biggest trade union in the UK with 1.3
Million members.

------
mtrimpe
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...](https://speakerdeck.com/mtrimpe/graphel-the-meaning-of-
an-immutable-world) which lists some of the real-world benefits of such a
language... feel free to use it for inspiration.

------
kirinan
Alright, I made an honest attempt to read through all of it but I still have a
fuzzy understanding of what you are trying to achieve with this project. I
understand our current development tools might not be the best, but if I
understand this right you are essentially making a framework into a language
with an editor with said language? I don't see that moving away from the model
we have now, simply moving things lower in the stack. Maybe Im just not
understanding.

------
the_why_of_y
How does this differ from other next-generation web platforms like Opa?

[http://opalang.org/](http://opalang.org/)

Also, why does this need to re-use the name of a next-generation file
synchronization tool?

[http://www.cis.upenn.edu/~bcpierce/unison/](http://www.cis.upenn.edu/~bcpierce/unison/)

~~~
duaneb
How does it improve on rsync?

~~~
LeoPanthera
Unison is bidirectional.

------
ganarajpr
While the ideas here are surely thought provoking - the most important factor
seems to be the User Experience of a Semantic Editor. How will a user perceive
this constrained environment ?

From what I can tell - users love freedom and computers hate them. Why else do
you think people still stick to text editors ? A plain text editor is probably
the most unconstrained environment there is. So, what is the best way to find
some sanity in between?

If you ask me, I would say that the main way to transform or change
programming would be to remove as much constraint as we possibly can from the
user. Let me crap all over the place - and you as the environment make sense
out of it. That is why we are building Dhi (
[http://www.dhi.io](http://www.dhi.io) ) - An AI Assistant to help you build
user interfaces. We are building it in such a way that the user has complete
freedom to say whatever he wants to say and we ( perhaps sometimes even with
the help of the user! ) plan to make sense of it. THAT is the dream.

------
xrstf
A few mockups or screenshots would have helped me immensely to understand this
"next gen text-based-programming killer", that is ironically described
exclusively in plaintext. In my head, ideas range from visual programming
language to programmable spreadsheet, with no clear picture of even how the
language looks.

I'm so confused...

~~~
PuercoPop
You see them at the author's blog
[https://pchiusano.github.io](https://pchiusano.github.io)

He's posted screenshot's and videos about this project. He has allocated 3
months to this project to see where it goes.

------
pshc
This is truly next-gen. It's going to eliminate so much of the bullshit work
in programming. Thanks so much for making it open source.

Plaintext must be killed. Long live real structure.

------
zwegner
This looks really awesome. I hope it takes off! I'm pretty curious what it
looks like though--as much as it shouldn't matter, syntax is very important.

There's a lot of overlap with how I want my language Mutagen[1] to work.
Merkle trees of syntax, details persistence/communication handled
transparently (or at least orthogonally to any other program logic). Where I
think this is most important though (and this description of the project
doesn't seem to mention) is _optimization_. Things like database
de-/normalization, data locality, and really so much more--pretty much
everything engineers do for performance rather than business logic--should be
in the hands of the compiler. Mutagen has been on hiatus for a while, but I've
been thinking about it a lot more lately, thinking where to go next. If
anybody is interested in it, let me know--I'd love some contributors to work
with, or even just people interested in optimization/compilers/functional
programming to talk to.

[1][https://github.com/zwegner/mutagen](https://github.com/zwegner/mutagen)

------
aikah
Show, don't tell.

~~~
jackmaney
But if you're going to tell, be concise and coherent.

~~~
nocman
Yes, 1000 times yes!

I know the author has a lot to say, but even after patiently wading through
the first few paragraphs I was not prepared to invest any more time in
figuring out what was so great about this project. The article title was
enough to get my attention, but I could not hang in there long enough to get
excited about (or even remain mildly interested in) the project.

Edit: OK, it was probably more like 50-60% of the first page that I read
through, not just the first few paragraphs.

------
desireco42
This all honestly resonates a lot with me. It sounds a little like LightTable.
It is not explained best, that is for sure. I still need to find and see
software, but provided there is one, I think his heart is on right place.

~~~
Alex3917
I think it's more analogous to Urbit than LightTable.

~~~
ibdknox
From what I know of his project, the best description is probably a vertically
integrated haskell-like language, fully structured editor (think paredit
without parens), and distributed framework.

So yeah, Urbit is a better analogue than LT :)

~~~
state
Except we don't have an editor ;)

------
smosher_
This could be interesting.

An observation: _users have accepted that computing is organized as a
constellation of rigid software appliances (“apps”) that never seem to work
well together and certainly can’t be composed or extended_

And yet, unless I have sorely misunderstood, Unison's editor is a browser-
based thing, which creates a barrier much more rigid than the ones surrounding
the tools I use today.

A question: does this just make web apps? I don't do webdev and nobody bothers
to mention it these days when they presume all the programming you do is for
the web.

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

Off-topic but.. by using Lisp one can refocus that 70% to actually solving
problems.

~~~
adamwk
Lisps can automatically define models, serialization and deserialization for
those models, and data persistence?

~~~
white-flame
The language allows it to be easily done. The model definitions can be simply
transformed into code that directly handles those individual model artifacts.

This is a super common paradigm in Lisp, especially when it comes to
class/structure/data definitions, where support functions of any type can be
generated straight from the defs. There is no "automatic" language feature
there, because no definition of "automatic" covers all useful cases. It's
simply easy to do because of the homoiconic nature of Lisp (code = data =
code, with easy manipulation to transform between them), and no real
distinction between compile time and run time.

~~~
orvr
Wrong. In CL there is a well defined distinction between read time, compile
time, load time and run time.

~~~
white-flame
Compile-time and load-time occur during run-time. The run-time context of
anything already executed is available to subsequent compile-time and load-
time contexts. Of course, these then further affect the run-time context going
forward.

While these "*-time"s are distinguished, they can be invoked and interplay
arbitrarily, unlike most other languages. It's all fundamentally run-time, in
contrast to those, especially when considering threaded environments where
compilation and run-time execution can happen simultaneously.

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

> Another 25% is spent on explicit networking. We don’t merely specify that a
> value must be sent from one node to another, we also specify how in
> exhaustive detail.

>Somewhere in between all this plumbing code is a tiny amount of interesting,
pure computation, which takes up the remaining 5% of developer time.

> These numbers are made up, of course, but if anything they are optimistic

Optimistic for your argument, that is.

~~~
wlievens
Yeah in my experience, the real time sink is the disproportionate cost of
making a decent user interface, regardless of framework or environment.

------
politician
> There are no parse or type errors to report to the user, since the UI
> constrains edits to those that are well-typed.

It may sound counter-intuitive, but if your editor makes it impossible to type
incorrect statements, it'll be really hard to learn/use/hack. Play is an
important (essential) part of learning.

That said, I think there needs to be more experimentation in this area, so I
hope you're successful.

------
pjdorrell
On the subject of using nameless hashes in software development, to "solve"
the naming problem, I wrote this article a while ago:
[http://thinkinghard.com/blog/DisorganizedIncrementalSoftware...](http://thinkinghard.com/blog/DisorganizedIncrementalSoftwareDevelopment.html).

------
mkapij
Sounded familiar, reminds me of:
[http://www.rebelscience.org/Cosas/COSA.htm](http://www.rebelscience.org/Cosas/COSA.htm)
[https://github.com/gocircuit/escher](https://github.com/gocircuit/escher)

------
PaulHoule
If you like this take a look at Inform7

[http://inform7.com/](http://inform7.com/)

------
kremlin
this...sounds...beautiful

I really enjoyed reading about functions being identified by their hashes, and
what advantages that could have.

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

------
geon
How much of this exists? Is there a screencast?

------
_pmf_
I'm not sure that implicitly calling your target customers lazy and/or
inefficient is such a great introduction.

~~~
totemizer
I am sure in the history there were some slaves which were inefficient, and I
wouldn't say that it was their fault. I think a lot of decisions are made
without asking the developers. Those decisions then impose situations when
planning for more than 3 months is meaningless, so we tend not to. And there
we are quite inefficient, especially from an external point of view. Don't
take offense where there is none.

------
ninjakeyboard
Akka's location transparency gets rid of a bunch of the network bs that the
first paragraph talks about.

------
danellis
What are your sources for the percentages in your about section? I have
trouble believing they're real.

------
joshstrange
> 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???).

------
M8
Will it have e.g. unsigned floating point types or it's the same old match-to-
hardware approach?

PS: might be a false dychotomy but then next-gen is an exaggeration.

------
_pmf_
It's LightTable all over again.

------
spot
back in the 80s CMU had an editor called "gnome" that also had the syntax
built in and so you could not make a syntax error:
[http://www.cs.cmu.edu/~pane/ftp/ILE.pdf](http://www.cs.cmu.edu/~pane/ftp/ILE.pdf)

i can't say i was a fan of using it.

but anyway, this isn't remotely a new idea.

------
jackmaney
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
> components:

> * The Unison language: a powerful, typed, purely functional underlying
> programming language

> * The Unison editor: a rich, in-browser semantic editor for editing programs

> * The Unison node: the backend implementation of the Unison language, its
> typechecker, and the API used by the Unison editor and other remote nodes in
> the network

> The collection of Unison nodes (the Unison web) form a network platform in
> which data and functions may be trivially exchanged, with a minimum of
> friction.

~~~
davedx
Pro tips:

* Be courteous when offering constructive criticism (that means, for example, don't swear at people)

* Often it's not the project owners posting things on HN - many projects aren't necessarily ready for public consumption when they end up on here

* This doesn't even appear to be a "product". It's an open source project that seems to have been recently put out there

Absolutely typical that this is the top rated comment. Hacker News, you SUCK.

~~~
dalek_cannes
Agreed. It's disturbing that there are so many members who are seemingly
intelligent, but either haven't read the guidelines or think that guidelines
don't apply to them.

------
anon3_
For anyone else with web programming library or framework: it helps to have
code snippets and screenshots on the page.

------
cromwellian
Posterchild for TL;DR

------
sabujp
Are you creating visual studio / visual basic but with some new language?

------
avarsheny
Can a day pass by without a new fucking programming language?

------
zak_mc_kracken
Why reinvent an editor from scratch? This is pretty much a guarantee that you
will get zero traction.

Your time would be much better spent writing a plug-in for Eclipse or IDEA.

