The adventure in blogademics continues: I have posted a draft of my next paper. Comments are welcome – the deadline is 5/19. Thanks to everyone who supplied references in response to my last post – you are in the acknowledgments.
Update – the link above is to the final version, pusblished as a tech report. I should add for those familiar with my UI work that there is almost no UI in this paper. I am trying to motivate and explain the model underlying my last two papers. It’s not just about ease of use – it is also about expressive power.
The flow of thought in this paper is excellent. I read the complete draft four times, because it crystallized a problem definition that is difficult to succinctly explain. It’s easy to observe that there is a lot of accidental complexity in hypermedia applications; explaining the solution requires that the emphasis is constantly on one question: what are the basic and characteristic properties of end-to-end system maintenance?
This paper stirs up ideas from many classic (known), simple (well-defined) situations that can quickly degrade software systems e.g. William Kent’s The Many Forms of a Single Fact. Your paper squarely nails how to tackle One Fact, One Place, One Time in end-to-end system maintenance. It’s often overlooked that One Fact can exist in more than one component at a time. Due to the fact components tend to be manifested as a class, attributes and operations are frequently co-located together.
In A generalized text editor, Christopher Fraser addresses a concept often missed by other authors: “Duplicating command scanners wastes programming effort. Duplicating command languages frustrates users, especially naive users: More than one typist has abandoned computing over poor user interfaces. As computers proliferate, more naive users must be accommodated; hence the growth of interest in improving command languages.” In this paper, Fraser essentially discusses what it might be like if all components in a system implemented a toString() method using “modularly composable transformation” semantics (and the Apache Software Foundation has addressed consistent toString methods in Java through the ToStringBuilder class that reflects upon type annotations to serialize nontextual data into text). Tying together Fraser’s subtle proposition for editing nontextual data with what Kent seeks to make obvious — that records exist in more than one format — we can begin to see there is not only an argument for modularly composable transformations, but a need for them in multi-language systems. After all, multi-language systems have some overlap in representing system artifacts.
(Another sharp observation by Fraser is: “Delaying the actual editing precludes error checking entirely, but it does result in a directory editor that exploits existing utilities without using more than one process at a time (a restriction imposed by
many operating systems), and that allows the user to back out of a bungled editing session without changing the directory.”; and his final comment about slave-process schemes using intelligent terminals hooked up to supercomputers warrants consideration for a future model of subtext and the general problem domain of integrated development environments.)
.NET’s Language Integrated Query (LINQ) offers some support for things like projecting objects and could even be used for selecting arbitrary differential subtrees, but it lacks a meta-programming facility. As a result, reflecting against the database schema is basically impossible to do strongly typed… which is the primary benefit of using LINQ. What people use in its place are “lightweight code generation” facilities that simply try to “beat the clock” by implementing strongly typed objects and executing the code fast enough to make the effort worth it. This is just another problem form where heuristics try to dominate the metamodel.
Is the operator := more than syntactic sugar?
E.g. couldn’t g invoke f in figure 10 e) like so:
g:: add
myf:: f
in: 3
in: myf.out
That is, with underscores instead of unpreserved whitespace:
g:: add
___myf:: f
______in: 3
___in: myf.out
[Joshua – Good question. There are two problems with that. First of all, g.myf.out will have the value 5, since you are overriding its ‘in’ argument to 3, and its ‘with’ is inherited as 2. The bigger problem is that the g.in : g.myf.out will try to treat the value g.myf.out as a number, and produce an error. The ‘:’ quotes its argument. The ‘:=’ unquotes the argument. This distinction is crucial for reflective functions that take pointers into code. I have tried different ways of making this distinction – the :/:= is just one way of doing it – but the distinction needs to be made somehow. — Jonathan]
Just wanted to say that I liked the paper. I stumbled a bit to understand your explanation on how you implemented the global positions, but that’s more of an implementation detail that isn’t too important to understanding the point of the paper anyway. I look forward to see what you come up with next.