It's LightTable all over again.
Unison: a next-generation programming platform
121–130 of 135 posts
Re: Unison: a next-generation programming platform
#122Wow, 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…
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…
Here's the link to MPS for those who don't already know what it is: https://www.jetbrains.com/mps/
Re: Unison: a next-generation programming platform
#123Earlier quoted context omitted.
> 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…
This sounds implausible. How can you run your intermediate program if it's missing a function? I don't see that accepting only well-typed programs changes anything, and furthermore it applies to all typed languages not just ones that enforce well-typedness by construction.
You can't run it. The point is that if I'm trying to figure out how to implement something, I can start writing down my ideas and adjust as I go. If I have to write valid code the whole time, my ability to do this is very limited.
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.
Re: Unison: a next-generation programming platform
#124Earlier quoted context omitted.
This sounds implausible. How can you run your intermediate program if it's missing a function? I don't see that accepting only well-typed programs changes anything, and furthermore it applies to all typed languages not just ones that enforce well-typedness by construction.
You can't run it. The point is that if I'm trying to figure out how to implement something, I can start writing down my ideas and adjust as I go. If I have to write valid code the whole time, my ability to do this is very limited. 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 th…
> 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.
Re: Unison: a next-generation programming platform
#125Earlier quoted context omitted.
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 repl…
Where are the demo videos? Couldn't find those and I'd be very interested to see them.
Here's the most recent video that I could find: http://pchiusano.github.io/2015-03-17/unison-update5.html
A few of the other posts have videos too: http://pchiusano.github.io/unison/
Re: Unison: a next-generation programming platform
#126Wow, 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…
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.
Re: Unison: a next-generation programming platform
#127On 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....
Re: Unison: a next-generation programming platform
#128Earlier quoted context omitted.
Lisps can automatically define models, serialization and deserialization for those models, and data persistence?
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"…
Wrong. In CL there is a well defined distinction between read time, compile time, load time and run time.
Re: Unison: a next-generation programming platform
#129Earlier quoted context omitted.
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…
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-…
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.
Re: Unison: a next-generation programming platform
#130Earlier quoted context omitted.
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…
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-…
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.
I'll definitely look at those papers though, could be missing something after all.