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

Re: Unison: a next-generation programming platform

#101

Post by pshc » Sat, May 09, 2015, 1:28 AM UTC

Garlef wrote: post #96

pchiusano wrote: post #56

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…

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

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

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

Re: Unison: a next-generation programming platform

#102

Post by pshc » Sat, May 09, 2015, 1:31 AM UTC

mnx wrote: post #31

Dewie3 wrote: 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.

Agreed; editor "slop" is important for UX. A structure editor needs to model a text editor, with all its indeterminacy, to be usable.

Re: Unison: a next-generation programming platform

#103

Post by groby_b » Sat, May 09, 2015, 1:42 AM UTC

hyperpallium wrote: post #76

nkassis wrote: post #64

Earlier quoted context omitted.

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…

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

Re: Unison: a next-generation programming platform

#104

Post by unimpressive » Sat, May 09, 2015, 2:34 AM UTC

pchiusano wrote: post #56

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…

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

Re: Unison: a next-generation programming platform

#105

Post by politician » Sat, May 09, 2015, 2:48 AM UTC

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

Re: Unison: a next-generation programming platform

#106

Post by wtetzner » Sat, May 09, 2015, 3:08 AM UTC

kyllo wrote: post #95

marcosdumay wrote: post #24

Earlier quoted context omitted.

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

Yes, but you have to finish typing the syntax first, and the IDE that is constantly parsing your code file is always going to report errors as the code goes through a broken state while you're typing. That's one thing Unison is trying to fix.

> That's one thing Unison is trying to fix. Is that actually a problem? If you're never allowed to input incomplete/broken code, then the way you program is very limited. Often I like to start writing a function, get to the point where I realize I need another function, write that one, and come back to the first function.

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.

Re: Unison: a next-generation programming platform

#107

Post by mbailey » Sat, May 09, 2015, 3:57 AM UTC

vezzy-fnord wrote: post #15

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

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

Re: Unison: a next-generation programming platform

#108

Post by tzakrajs » Sat, May 09, 2015, 4:02 AM UTC

ripter wrote: post #3

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

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.

Re: Unison: a next-generation programming platform

#109

Post by cplease » Sat, May 09, 2015, 4:12 AM UTC

tlarkworthy wrote: post #83

jackmaney wrote: post #7

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…

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.

That's not serialization.

Re: Unison: a next-generation programming platform

#110

Post by Ericson2314 » Sat, May 09, 2015, 4:56 AM UTC

bcg1 wrote: post #12

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

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.