Unison: a next-generation programming platform
unisonweb.org
unisonweb.org
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 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.
"The program is a UI, and UI interaction is programming. Unison panels take the idea of spreadsheets, which blur the distinction between UI interaction and programming, to its logical conclusion."
...this blurring between programming and interaction (which I've also thought of) probably offers a potentially viable path to much more powerful voice control of devices, since programming APIs serving as user interfaces can now also (besides graphical UI) implicitly define strict grammars for structured voice input. That's the one thing I thought of that I didn't see mentioned there.
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.
A few of the other posts have videos too: http://pchiusano.github.io/unison/
When I was working on it before my approach was to use grammatical knowledge of traditional, text-based languages to generate a selection of grammatically valid constructs for your current 'cursor' position; only in the last few weeks did I hit on the idea to do it 'syntax-free' (in my terminology).
My thinking on why 'syntax-free' is The Way to go: if you look at what someone's trying to do when writing a program, it's really: (1) select language construct (2) select parameters as a 'configuration' of selected construct. Text is one way to specify those things, but a far more effective system addresses the fact that that's all you're doing directly, and allows views to be attached after the fact (even if something that's primarily text ends up being the optimal view!).
In case it's helpful to you for communicating the idea to people, I often described the benefit of this kind of system to people as automatically allowing someone who only knows how to read a language, to also be able to write in it—no more remembering the details of how to express construct X in language Y.
My most recent attempt: https://github.com/pshc/archipelago
Few questions:
* how is your editor different from MPS (except being browser based)?
* how does your project compares to an implementation on top of language workbenches?
* do you think your assumption about time spent on a project is mostly Haskell related or is that for some specific types of projects?
* are you thinking about implementing some framework of your own or do you have some other in mind?
* do you plan on integrating with existing libraries or write your own implementation?
And comments:
* for me good IDE feels like semantic editor. I'm inclined to believe that text based editor can have all the good features of semantic editor and avoid most of the bad ones.
* while writing simple structures one time and reusing them vertically in a project is useful, it's doubtful that it's worth while. It becomes worth while only if you have project in multiple languages/technologies. But mostly if you can do refactoring automatically (even database schema migrations).
* try to explain your project better, this should help you with narrowing it's scope. Most of the people will try to fit it into some category they are familiar with so emphasize the distinctions.
Good luck! ;)
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.
> 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.
> 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...
Starting from scratch can yield radically better solutions than how tech/market happened to evolve.
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.
So, yes, decades. Not necessarily solved well, but yes, people shipped data over the network before JS ;)
I also suspect (being a language design geek, and also having worked with some very large distributed systems) that the reason why this is seductive is also why it's unworkable. I think I probably do spend close to 70% of my time dealing with networking and data formats (and yes, I use off-the-shelf serialization formats and networking protocols), but that's because a watch is very different from a phone which is very different from a persistent messaging server which is different from a webpage, and Bluetooth is very different from cell networks which are very different from 10G-Ethernet in a DC. Try to dump your server data structures directly to your customer's cell phone and you're about to have a lot of performance and security problems.
> These numbers are made up, of course
> These numbers are made up, of course...
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.
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.
A poor analogy might be the difference between speaking words verbally to form a sentence vs. shuffling through a stack of index cards to find the right words to arrange on a table to form a sentence. The latter would be useful if you were just learning a language, but once you know how to speak it, that would be an enormous waste of time.
In an editor where only working code can be input, you can't do this style of programming, which almost rules out exploratory programming. You have to more or less know what you're doing from the start.
If you already know what code you want to write, this makes sense. But how often does that happen? I suppose you could work out your ideas on paper first, but that eliminates the much of the value modern editors provide.
What would be ironic is if this semantic editing would force us to sketch our functions/modules/program with pen and paper before we are able to actually input them into this semantic editor. An editor that tries to go beyond the "archaic" textual interface, and ends up forcing you to use the even more "archaic" pen and paper.
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 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.
I've developed plenty of advanced IDE infrastructure; e.g. see
http://research.microsoft.com/en-us/people/smcdirm/managedti... and http://research.microsoft.com/en-us/projects/liveprogramming...
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.
I've refined the technique over the last 7 years, you can read about it in a conference paper:
http://research.microsoft.com/pubs/211297/onward14.pdf
You can think of Glitch as being like React with dependency tracing (no world diffing) and support for state (effects are logged, must be commutative to support replay, and are rolled back when no longer executed by a replay).
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.
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.
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.
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.
Also, why does this need to re-use the name of a next-generation file synchronization tool?
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 ) - 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.
I'm so confused...
He's posted screenshot's and videos about this project. He has allocated 3 months to this project to see where it goes.
Plaintext must be killed. Long live real structure.
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.
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.
http://www.joelonsoftware.com/articles/fog0000000018.html
> That's one sure tip-off to the fact that you're being assaulted by an Architecture Astronaut: the incredible amount of bombast; the heroic, utopian grandiloquence; the boastfulness; the complete lack of reality. And people buy it! The business press goes wild!
So yeah, Urbit is a better analogue than LT :)
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.
Off-topic but.. by using Lisp one can refocus that 70% to actually solving problems.
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.
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.
> 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.
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.
I really enjoyed reading about functions being identified by their hashes, and what advantages that could have.
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???).
PS: might be a false dychotomy but then next-gen is an exaggeration.
i can't say i was a fan of using it.
but anyway, this isn't remotely a new idea.
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.
1-2 months to research Elm and transition the Unison editor? Okay that's all I need to know.
Realistically you would probably only be able to work part-time because you are a paid consultant? Okay cool that's self explanatory, you need to make money and we get that.
This article is informative, but it could've been edited to a maximum word count.
P.S. Thanks for being mature. I willingly admit that I'm young and I have a lot to learn, but I do happen to know terms like HTTP+JSON and why a one-file-per-hash system is an insanely inefficient implementation.
* 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.
Very constructive and courteous.
Your other points are right (I winced at that "what the fuck your product is", and I bet most readers did), but this one isn't. Acerbic dismissals are a problem on HN, but they're far from "absolutely typical".
The trouble with that false generalization is that it conditions us to see the community the wrong way. Repeat too often that a town doesn't care about litter, and more people will be careless with their trash. But users here do care.
It's better to view this systemically, as a tragedy-of-the-commons problem that we all need to work on, than to make a big blaming judgment as if it were easy for things to be better. They should indeed be better—but it's not that easy. What is easy is to see it as everybody else's problem ("Hacker News, you suck"). In reality, anybody commenting on Hacker News is part of it, so we're talking about ourselves.
Your time would be much better spent writing a plug-in for Eclipse or IDEA.