Interesting new programming language idea from JonathanEdwards
Interestingly, it presents program as a structured document without distinction between write-time and execution.
The main operation is copying and making variants on subsections of the program / document. All copies are dynamically linked back to the prototype, and there's a kind of inheritance: when the prototype changes, so does the copy.
Calling functions is also a kind of copying ... of other parts of the program into parameter slots. Thus execution is a kind of rewriting.
This has a lot of really great potential and should be explored with gusto, but I think the idea of having a language in which the fundamental structure of the code is not fully viewable in any kind of plain text form (which the JonathanEdwards
demo says he's promoting) is not so good.
There do need to be name scoping rules, and the editor should display fully qualified names when there's a potential ambiguity. To support copy/paste editing, temporary name clashes within the same scope should be allowed, but not canonical, and should be displayed as warnings. Looking at connecting lines should not be the only sure way to identify links in fully expanded, canonically correct code.
Very interesting. Great demo tutorial. Since there is no run-time, presumably there can't be any infinite loops so I wonder if that makes the language Turing-incomplete (which isn't a criticism). I also worry that the compass link designator will get unwieldy once programs exceed one viewable page in size. Comments?
- Perhaps, Turing completeness (if needed) could be added by allowing tail-recursive operations to be designated as unrestricted, and/or restricted by time-out rather than call depth (Turing complete if CPU speed is infinite <g>).
- No: I is very well TuringComplete, And I guess you could wait quite a time for an update of calculated values, if you used the AckermanFunction? instead of the simple factorial example. There is a some runtime, and one of the shortcomings may just be that it is not visible. Maybe pending executions of partial results should be inspectable (which should be easy to implement, after all, it's just another viewing/editing option).
- Screen splitting could be used to show link lines that don't fit on one full-screen page.
- But large programs will lead to problems in this regard in any case.
I'll check back when the SubtextLanguage
environment will be implemented in SubtextLanguage
. That should convincingly test author's assertion that programming is inhumanly hard and harder than it needs to be and that this gizmo will "make programming fundamentally easier".
Until then, the BS factor in the paper presented at OOPSLA is so embarrassing that it is only a testimony to the OOPSLA committee's crass incompetence (it was hardly not the only paper in this state). Luckily, next year ICFP is coming back to US shores.
But it is a new concept anyway. The nearest language/concept I can come up with is TeX, which interweaves text and code too but not interactively so. I once imagined what an interactive variant of Tex would look like. I was inspired by Display-PostScript and wondered what the result would be if one didn't start with PostScript, but TeX. I though a fitting name would be eXo (with a Chi and pronounced echo emphasizing its interactiveness.