3 ms·

Hm, your answer is not what I was expecting :) Some follow up questions if you are up for it: What are the fundamental features of Dark that are not possible t

Hm, your answer is not what I was expecting :) Some follow up questions if you are up for it: What are the fundamental features of Dark that are not possible to add to an existing language? What are the fundamental features of an existing language that are not possible to restrict via enforcing a subset, that are fundamental to Dark? Is Dark a very domain specific language? Perhaps these questions will better be answered by a demo that is coming in September.

pbiggar 7y ago
> What are the fundamental features of Dark that are not possible to add to an existing language? An obvious example is the structured editor. To do that, we have to have a language in which there is a meaning to every incomplete program. Other languages don't have that - they just have a syntax error. Our editor shows you what we call "live values" as you type. If you've seen lighttable, it's a similar idea. We save real values from production and use it an a sorta debugger. It's really wild, makes understanding code really easy, and debugging too. How would we handle that in JS? No idea, might be possible by hacking into v8. But even then, we actually needed to change the language semantics and require all functions to be marked as "pure" or "impure". And then we discovered there's a 3rd state: "non-side-effecting but we don't have a version of it in the client". And then a 4th state "not idempotent but we can it without side-effects". I doubt there's anything that _couldnt_ be done in Js or ruby or python, but what's the point in fighting that battle? By controlling the entire thing we avoid all this. Same as why we don't support vim. Could we make all the cool stuff we're doing work in vim? Sure, with a massive massive effort. Blank slates work better for this.

3 ms·

Hm, your answer is not what I was expecting :) Some follow up questions if you are up for it: What are the fundamental features of Dark that are not possible t

by alexashka 7y ago

pbiggar 7y ago
> What are the fundamental features of Dark that are not possible to add to an existing language? An obvious example is the structured editor. To do that, we have to have a language in which there is a meaning to every incomplete program. Other languages don't have that - they just have a syntax error. Our editor shows you what we call "live values" as you type. If you've seen lighttable, it's a similar idea. We save real values from production and use it an a sorta debugger. It's really wild, makes understanding code really easy, and debugging too. How would we handle that in JS? No idea, might be possible by hacking into v8. But even then, we actually needed to change the language semantics and require all functions to be marked as "pure" or "impure". And then we discovered there's a 3rd state: "non-side-effecting but we don't have a version of it in the client". And then a 4th state "not idempotent but we can it without side-effects". I doubt there's anything that _couldnt_ be done in Js or ruby or python, but what's the point in fighting that battle? By controlling the entire thing we avoid all this. Same as why we don't support vim. Could we make all the cool stuff we're doing work in vim? Sure, with a massive massive effort. Blank slates work better for this.