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

Re: Unison: a next-generation programming platform

#131

Post by seanmcdirmid » Sun, May 10, 2015, 9:31 AM UTC

Ericson2314 wrote: post #129

seanmcdirmid wrote: post #112

Earlier quoted context omitted.

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…

Coupled with type inference, which you will need if you use a structured editor or not, then incremental type checking is indeed very non functional.

Re: Unison: a next-generation programming platform

#132

Post by EricSu » Sun, May 10, 2015, 5:09 PM UTC

teacup50 wrote: post #98

EricSu wrote: post #34

Earlier quoted context omitted.

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

I understand clearly what it is; perhaps it's only fluff to you because it's aimed higher than your technical reading level?

Please tell me how things like "I am kind of kicking myself for making what ended up being a bad tech choice..." and "gak!" are directly informative of the point of the article? This article needs to take a tl;dr approach and cut down the statements that could be stated in one sentence. Maybe other people might want to know this guy's thought process behind everything, but I'm much more engaged with the cold facts.

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.

Re: Unison: a next-generation programming platform

#133

Post by white-flame » Mon, May 11, 2015, 11:19 AM UTC

orvr wrote: post #128

white-flame wrote: post #82

Earlier quoted context omitted.

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.

Compile-time and load-time occur during run-time. The run-time context of anything already executed is available to subsequent compile-time and load-time contexts. Of course, these then further affect the run-time context going forward.

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.

Re: Unison: a next-generation programming platform

#134

Post by Ericson2314 » Mon, May 11, 2015, 7:51 PM UTC

seanmcdirmid wrote: post #131

Ericson2314 wrote: post #129

Earlier quoted context omitted.

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…

Coupled with type inference, which you will need if you use a structured editor or not, then incremental type checking is indeed very non functional.

We agree incremental use of global type inference algorithms is non-function.

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.

Re: Unison: a next-generation programming platform

#135

Post by seanmcdirmid » Mon, May 11, 2015, 9:42 PM UTC

Ericson2314 wrote: post #134

seanmcdirmid wrote: post #131

Earlier quoted context omitted.

Coupled with type inference, which you will need if you use a structured editor or not, then incremental type checking is indeed very non functional.

We agree incremental use of global type inference algorithms is non-function. 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.

You will need type inference if you want any sort of non local communication...e.g. variables that hold different values or functions. But ya, if your language is just pure trees with no names or symbol tabkes, you don't need it; not very useful, however.