"..programming language designers should design languages that have no mapping dilemmas in them. ..if the compiler writer can't make the best choice for everybody, the features shouldn't be in the language. This is the fork in the road at which the C community and the Lisp community split. ..in the absence of a clear principled solution to the problem of mapping dilemmas and mapping conflicts, the Dijkstra choice, the C choice, was the right choice."
---
I'm reminded of an old conversation with rocketnia around Dec '10 (http://arclanguage.org/item?id=13219). I was concerned with the same problem, but what I was suggesting there turns out to have been even more extreme than Kiczales's notion of open implementation (which hadn't been on my mind at the time)
---
Surprisingly recent HN discussion: http://news.ycombinator.com/item?id=2550962. I particularly liked all the comments around 'protocols'. What's a protocol? Is it different from 'abstractions' in just that it's overrideable and extensible?
"It would mean that in addition to having descriptions that were more or less detailed, we would have descriptions that were about different aspects of the system, because no one kind of description is going to capture everything that matters. (This is something the other engineers have had.) [...] Now the key point in getting all of this to work is to arrange the descriptions to that we can take advantage of what one description doesn't say, to turn around and say it in a different description."
Reminds me a bit of UML. :-p
"Achieving this kind of separation has been the focus of much open-implementation research. A primary focus has been the concept of computational reflection, which explores issues of how modules can provide interfaces for examing and adjusting themselves - that is, how modules can provide meta-interfaces. Although this may sound somewhat esoteric, it is exactly what open implementations need - an interface for controlling the implementation strategy that sits behind the primary interface." (http://www2.parc.com/csl/groups/sda/projects/oi/ieee-softwar...)
And that reminds me of dependency injection frameworks. ^_-
That's not to say Kiczales has UML or dependency injection in mind, just that those camps (or at least their stereotypes) worry about the same things. ...Which probably isn't surprising, since it's all programming. :-p
Speaking of which, I've actually been worried about both these issues recently.
I've had a massive interactive story idea in mind for a few years now (http://rocketnia.wordpress.com/2009/04/26/dun-dun-dunnnnn/), and the task of planning out such a story currently has me thinking in terms of describing the automaton-like system of the fictional world in terms of several subplot descriptions which somehow coexist and flesh each other out (no clue how yet).
Meanwhile, I just looked at my Penknife draft in a somewhat new light today, as a language which needs as obvious an implementation of things as possible in order for the action of extending a core utility to have predictable consequences. I've already been avoiding complicated algorithms for fear that they'd be wrong, have unstable APIs, or be hard to customize, and at some point I probably even thought about this practice as a form of putting the implementation out in the open, but something feels different about saying that today. Dunno if it's good or bad. ^_^
Alternatively, sometimes I think of 'extend style extensibility in terms of implementation inheritance from the language (and libraries) to the application. That doesn't sound pretty at all. :-p But that probably won't stop me.
