I want to emphasize that even more important than which side we see a model working from is Hal's distinction between solution space and problem space and the gap that represents between the users of systems and the builders of systems.  One way that gap arises in conversations that anderbill and I have is in terms of a Requirements Gap. It is important not to close the solution-problem gap, but to bridge it.  The gap is important, and its first value is in recognition that it is there.
 

Tim Bray points to piece by Jeff Dillon that talks briefly about Java interfaces and Java platform independence.

The claim here is that Java interfaces are all constructed to be platform independent, whereas .NET and mono interfaces contain platform (read, OS specific) elements that require further wrapping, if they are to be portable.

This made me think of the discussion here on models. It will be interesting to see how we go from a platform-independent (?) Java interface for a Peano Numeral to a program running on a computer that uses them. What dependencies will be required?

I think we're trying to separate models(?) (and programs(?) is it possible?) from specific OS platforms, as well as the meaning ascribed to interfaces when they are instantiated in programs that execute on platforms.
 

Hi Bill, I think you are onto something.

It seems to me that Tim was talking about libraries more than the interface mechanism.

The concern seems to be about what gets exposed through interfaces. The pet illustration is the weight of relying directly on something like an exposed access to the Windows registry model. If something like that is not properly abstracted, having a good portable interface and a straightforward rehosting is a concern.  I run into the same thing looking for an open-source Wiki that I can rehost under ASP and also not require me to install MySQL (or any database, in fact).

It looked to me that such dependencies were what kept COM and DCOM from being readily-ported onto other platforms.  The System Control Manager (SCM) and libraries that supported COM were so heavily welded into Windows that it was expedient to drag a pile of Windows OS functions with it to make easy hosting on Unix, for example.  That turned out to be a seriously-unnatural act, as far as I can tell.  The same thing was done to provide an adaptor layer on FreeBSD for the Shared-Source version of the CLI.  (I presume that Mono doesn't have that problem, considering all of the places they are hosted, so this wasn't an inescapable situation for .NET or for DCOM thanks to the miracle of refactoring.)

You can have a similar problem with Java, of course.  The Sun folk insisted that Eclipse was digging that kind of hole, and maybe they have.  It may taste a little different, but the consequences cam be the same once there's a reliance on substantical closed-source or very-specific implementations (think MySQL), including embedded operating-system functions.

I want to take this off into a separate Numbering Peano entry to suggest how interfaces (especially the Java-language facility of that name) aren't platform-independent either.  I'm interested in the question of how does one use a platform-specific facility to accomplish platform-independent functionality, and is it even meaningful to speak that way?  More later.
 

Oops, it isn't Tim Bray who put together the comment, it is, as Bill Anderson noted, Jeff Dillon at http://blogs.sun.com/roller/page/jeffdillon/20040609#net_and_mono_the_libraries.  I agree with both of them: "It's the libraries, stupid," and Bill's questions cut right to it.  And, it's not just the libraries, heh, heh, heh.