Unison: a next-generation programming platform

http://unisonweb.org/2015-05-07/about.html

by adamwk • 11 years ago

308 128 11 years ago

jackmaney4• 11 years ago

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.

jackmaney4• 11 years ago

As with many things in life, there's also a relevant xkcd: https://xkcd.com/927/

banebot• 11 years ago

This was the first thing that came to mind about a paragraph into reading

woah2• 11 years ago

There should be an xkcd about people overusing that xkcd in every possible context

geon2• 11 years ago

I don't see how that is relevant. The author's complaint isn't that there are too many languages, but that none of them are good enough.

mtrimpe2• 11 years ago

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.

vinodkd• 11 years ago

this was strangely entirely grokkable, thanks.

irickt• 11 years ago

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

EricSu2• 11 years ago

....which is also 8 paragraphs of fluff and trying to connect with the audience

davedx• 11 years ago

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• 11 years ago

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.

benihana• 11 years ago

Hacker News, you SUCK.

Very constructive and courteous.

dang• 11 years ago

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.

callum85• 11 years ago

This isn't a 'Show HN'.

ripter• 11 years ago

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.

jackmaney4• 11 years ago

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

mercurial• 11 years ago

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

hyperpallium3• 11 years ago

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.

nostrademons• 11 years ago

I suspect that "how to structure my data for serialization" is what the author means by the 70% of time spent on parsing, serialization, and persistence. I hadn't heard of Unison before, but I recognize the author's name from Lambda: The Ultimate, and I suspect that what he has in mind is that any value within the Unison language can appear on any Unison node, transparently. Instead of picking out exactly which fields you need and then creating new JSONObjects or protobufs for them, just send the whole variable over.

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.

tlarkworthy• 11 years ago

I didn't read it as getting your data serialized for storage, I read it as serializing your data between different libraries of a program. You know, putting the arguments to a function the right way round, changing the structure so that library A can talk to library B. I do spend a fair amount of time doing that, and it would be solved by a more semantic approach.

breadbox• 11 years ago

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

These numbers are made up, of course

hyperpallium3• 11 years ago

I agree on parsing/serialization/persistence; but when interacting with a new JSON format, although the parsing is free (via a library), you still have to interpret/bind/integrate it into your own app's data structures. Often this is implicit in looking up values in the JSON, then calling something with them - but there's still that intermediate layer. If you're often dealing with new JSON formats (and I think most developers aren't), this integration/gluing would take up a large proportion of development time.

slowmovintarget• 11 years ago

Followed by:

These numbers are made up, of course...

tzakrajs• 11 years ago

I have no idea what world the author comes from, but it doesn't remind me of my day to day development efforts using Python.

kirinan• 11 years ago

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• 11 years ago

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

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/

duaneb• 11 years ago

How does it improve on rsync?

LeoPanthera• 11 years ago

Unison is bidirectional.

aikah• 11 years ago

Show, don't tell.

jackmaney4• 11 years ago

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

nocman• 11 years ago

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.

blakeyrat• 11 years ago

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!

teacup502• 11 years ago

Unless you're trying to be precise and detailed (as opposed to spewing startup advertising), in which case "tell" is exactly what you should be doing.

cromwellian• 11 years ago

Posterchild for TL;DR

mtrimpe2• 11 years ago

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.

bcg1• 11 years ago

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.

Dewie34• 11 years ago

The editor (or whatever it's called) promises to only allow only well-typed programs. Not just syntactically correct programs.

marcosdumay• 11 years ago

Eclipse, Visual Studio, and all the Haskell IDEs catch type errors on the fly and help you fix them.

desireco423• 11 years ago

It is very limited, I am a vim guy, it has nothing to do with vim. Simply we are reinventing the wheel every time and that is the biggest issue.

Ericson23143• 11 years ago

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

seanmcdirmid4• 11 years ago

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

vezzy-fnord• 11 years ago

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• 11 years ago

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

chippy• 11 years ago

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

mbailey• 11 years ago

Had this same thought, there's a lot of things named unison, including some really popular ones.

Animats• 11 years ago

It's also a category of inventions, "Unison devices", which refer to ways to keep two things in sync. This was a huge problem from about 1850 to 1980 or so. Edison's stock ticker was one of the first big successes, but it wasn't really nailed until the invention of the phase-locked loop. (Anyone remember "horizontal hold" knobs?)

joshstrange• 11 years ago

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

pjc50• 11 years ago

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.

pshc3• 11 years ago

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.

ninjakeyboard• 11 years ago

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

panic• 11 years ago

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 like to use the finished product would help.

DennisP• 11 years ago

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

waynecochran• 11 years ago

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

melloclello2• 11 years ago

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

desireco423• 11 years ago

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.

Alex39172• 11 years ago

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

ibdknox• 11 years ago

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 :)

desireco423• 11 years ago

Thanks for that reference.

woah2• 11 years ago

Like Urbit but less crazy I'm guessing?

geon2• 11 years ago

How much of this exists? Is there a screencast?

xrstf• 11 years ago

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• 11 years ago

You see them at the author's blog 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.

M8• 11 years ago

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.

fasteo• 11 years ago

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• 11 years ago

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

mkapij• 11 years ago

Sounded familiar, reminds me of: http://www.rebelscience.org/Cosas/COSA.htm https://github.com/gocircuit/escher

zwegner• 11 years ago

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

pchiusano• 11 years ago

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

jakub_h2• 11 years ago

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.

jimfleming2• 11 years ago

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• 11 years ago

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

westoncb• 11 years ago

I think the time is ripe for this kind of software: I'm also working on something very similar. I've put a lot more work into the editing/layout features than the portion for generating the AST—but my scheme for doing it is nearly identical to what you have in your video. A demo video of my editor is here: http://symbolflux.com/projects/tiledtext

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.

white-flame3• 11 years ago

One term I didn't see on the page, but you should look into examples of if you already haven't, is "structure editor". That's the notion of a source code editor which doesn't allow free-form text editing, but creation of well-formed language semantics.

melloclello2• 11 years ago

Also, "tree editor".

shasta• 11 years ago

Awesome project. Ignore the haters. I think this (https://pchiusano.github.io/2015-04-23/unison-update7.html#r...) was the link that I found most helpful to get an idea of what you're doing, of the random set of pages that I flipped through.

Garlef• 11 years ago

Hi There. I'm just here to get in line for a "I've been working on something similar..." comment. Nice work!

pshc3• 11 years ago

Same here. Well, s/working on/pondering and failing at/ for me :P

My most recent attempt: https://github.com/pshc/archipelago

unimpressive• 11 years ago

This is extremely relevant to my interests and something I was pondering beginning work on. It makes me very glad (if not feeling a bit unoriginal) to hear that so many other people had plans to do similar. :)

zapov• 11 years ago

As someone with a "similar" platform, I too am rather surprised this end up on HN frontpage ;(

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! ;)

Flow• 11 years ago

Here's the link to MPS for those who don't already know what it is: https://www.jetbrains.com/mps/

xmonkee• 11 years ago

Can I summarize this with: immutable lisp with 2-way bindings to m-expressions? Sorry I don't mean to trivialize or anything, but me and my friends have been thinking of something eerily on these lines. I think it's one of those ideas whose time has come. After reading your descriptions I think I have a better idea in my mind of what I was grasping at earlier. We were pretty inspired by Elm and you seem to be too.

danellis• 11 years ago

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

hydandata• 11 years ago

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• 11 years ago

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

white-flame3• 11 years ago

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.

zak_mc_kracken• 11 years ago

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.

anon3_• 11 years ago

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

kremlin• 11 years ago

this...sounds...beautiful

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

ganarajpr• 11 years ago

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.

spot• 11 years ago

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

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

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

PaulHoule• 11 years ago

If you like this take a look at Inform7

http://inform7.com/

avarsheny• 11 years ago

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

sabujp• 11 years ago

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

politician• 11 years ago

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.

smosher_• 11 years ago

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.

_pmf_2• 11 years ago

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

totemizer• 11 years ago

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.

_pmf_2• 11 years ago

It's LightTable all over again.

pjdorrell• 11 years ago

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

Unison: a next-generation programming platform

Related Stories