Live data from Hacker News

Unison: a next-generation programming platform

unisonweb.org

71–80 of 135 posts

Re: Unison: a next-generation programming platform

#71

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 the…

The things you're describing are EERILY similar to some stuff I've been conceptualizing and thinking about recently, as inspired by the VPRI people's work/OMeta/Shen. I'd just remark that...

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

Re: Unison: a next-generation programming platform

#72
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 ) - 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.

Re: Unison: a next-generation programming platform

#73
post #28

Here are some more blog posts about the project: 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 l…

Interesting to see he's also the author of the book Functional Programming in Scala.

Re: Unison: a next-generation programming platform

#74

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 the…

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.

Re: Unison: a next-generation programming platform

#75
post #6

Show, don't tell.

It mostly reminded me of Spolsky:

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!

Re: Unison: a next-generation programming platform

#76
post #64

Earlier quoted context omitted.

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.

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.

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.

Re: Unison: a next-generation programming platform

#77
post #31
post #25

Earlier quoted context omitted.

The difference is that this editor will supposedly not even allow the code to be in a state of type errors . You literally can not construct a program that is not well-typed. Don't ask me how that editing experience is supposed to work, or if it's a good idea.

Actually, that sounds terrible. I already am sometimes annoyed when I try to first use a variable, and then go back and decide where should I declare it - visual studio doesn't like that - literally not being able to go through a broken state would be annoying.

If this video http://pchiusano.github.io/2015-03-17/unison-update5.html > is an example of this, then yes, it does look annoying and inefficient. Now I'm not sure if I understand exactly what he's doing here, but it looks like something along those lines: rather than inputting what he wants directly via the keyboard, he has to choose a pattern (like variable-operator-variable) from a drop-down list, and then tab between the fields to fill in the pattern.

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.

Re: Unison: a next-generation programming platform

#78
post #44

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…

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 ra…

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

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.

Re: Unison: a next-generation programming platform

#80

Earlier quoted context omitted.

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

He addresses this issue - see the part about using hashes for everything so neither names nor lib versions matter, only the contents do, identified by hashes.
Post reply on HN