Collaborative articulation of how abstraction and language is employed in the computational manifestation of numbers -- including analysis of the role of syntax, semantics, and meaning in the specification and use of software interfaces.

Recent Items
Deja Double Vu
Blog Restored
Unorganized set of references: to be evaluated
Document-centric integration; perils of API's
Libraries and Platform Independence
"External" Interface Contracts
Interfaces, Protocol Extensibility, and Versioning
A Fine Kettle of Fish, indeed.
What Is a Model?
A Fine Kettle of Fish

Archives
2004-05-30
2004-06-06
2004-06-13
2004-06-27
2004-08-22
2004-08-29

Document-centric integration; perils of API's

Just a quick bookmark of this article on perils of API's.

Haven't read it closely; might be off the mark. But it does seem related to our exploration of contexts and tacit understandings required to use certain kinds of API's.

A critical read is required.

posted by Bill Anderson at 6/18/2004 06:48:10 AM

Libraries and Platform Independence

Libraries and Platform Independence

Jeff Dillon: .NET and Mono - The Libraries.  Spotted by Tim Bray, this is an interesting piece that anderbill commented on.

I doubt that there is ever a way to prevent platform dependency (name your degree of dependence) using practical general-purpose development platforms.  For me the debate comes down to how does one want to arrive at a disciplined way of providing for platform dependence and also managing the risk of platform trap-in (name your degree of portability).

Miguel de Icaza responds to that question in his 11 June 2004: On .NET and portability entry, also commenting on Jeff's implied comparison with Java.  Miguel points to the sort of portability found with Mono that allows platform dependence where it matters, including in the open construction of more-independent layers and interfaces above those constructions.  It is valuable to notice that the Mono folks have demonstrated an open-source implementation of Java running atop the Mono CLI, making cross-platform libraries available to Java developers as well as platform-specific ones.  In case you missed it, let me say again:  Java has been hosted on .NET and you can have platform-dependent implementations of libraries as well as platform-specific libraries as much as you want (or not).

Scott Hanselman and others chime in to point out that the namespaces in the .NET libraries are partitioned in a way where the use of platform dependency is kept isolated and explicit, although one commentator suggested that it isn't so simple.  Scott also declares his own preference for a blended way of moving up and down the dependency spectrum.

Ian Bicking nails it with his early comment: "The best situation, IMHO, is where the applications can be written in a portable way, but all the libraries have the option to do platform-specific things."

The business about the language versus the platform/API/libraries is a bit daunting.  It is the direction we've taken, with (relatively) small languages and large libraries.  In another forum, Chris Rathman raises questions about the move toward code generation, a seemingly independent topic, but for the reference to Blanchard's Law: "Systems that require code generation lack sufficient power to tackle the problem at hand."

Uh oh.  When I worked in functional-programming systems around 1965 when Peter Landin's "The Next 700 Programming Languages" was presented, it seems to me that code generation is the whole deal.  In effect, code is being generated all of the time in an applicative system, and if you can make a closure (a "computed" program for a function) persistent, it might be more than "in effect."  I don't want to promote that here (hmmm, maybe later), but it does bring to mind the consideration of binding time.  Maybe this debate is really one about where and when and how often one does binding to underlying implementations, and is there a platform-independent way of doing that?  That does tie back to the Model-Driven Architecture (MDA) conversation and so this will come up again. In particular, we need to re-examine the notion of "high-level" in terms of problem spaces versus solution spaces, and also ponder where higher-level (in the sense of languages) went while we weren't looking.  This currently-inaccessible post attributed to Nathan Myers might help in terms of the relationship to abstraction:

"Once upon a time, the adjective "high-level", applied to a programming language, denoted an increased degree of expressive power, implying not only economy of expression -- terseness -- but an ability to encode new abstractions encapsulating notions not actually envisioned by the language designers themselves.  In the decades since the lambda calculus was first elucidated, and embodied to increasing degrees in the LISPs and their successors, language designers have learned to enable many different kinds of abstraction, and have increasingly concentrated on providing the scaffolding needed to manage the complexity that comes with such power.  Modern languages like Common Lisp, Dylan, and Haskell embody much of what has been learned.  Modern scripting languages like Python and Ruby bring some of the lessons to the masses.  But the term 'high-level' has lately been abused to describe languages which offer none of the power it has been taken to imply, but instead only incidental details of those languages' typical implementations.  This misuse is most egregious for the case of Java and C#."

But first, I need to deliver on my claim that Java interfaces are not all that platform-independent, thank you very much.

posted by orcmid at 6/14/2004 03:09:58 PM

"External" Interface Contracts

"External" Interface Contracts

Don Box's Spoutlet: Objects as Web Services Again and Again and Again.  Don Box clarifies something that has always puzzled me.  When I first saw COM in 1992, it was clear to me that the interface approach had great legs, being a simple, versatile approach to plug-and-play dynamic configuration of components.  That is not the path that was taken to .NET and I couldn't figure out why, unless it was because developers couldn't see the point of being restricted to interface contracts (and persisted in thinking that COM was too hard).  Here Don seems to confirm that it was indeed out of a "the customer is always right" approach, quoting Steve Vinoski.

I subscribe to the notion that the customer is always right.  I don't think that is entirely what happened here.  I think what happened is that the model was changed to be object- (rather than interface-) centric for other reasons, including comprehensibility in the context of Visual Basic.  I suppose there was no thought to an exit plan at that point, and I also suspect that there was not enough exploration of how to preserve the component model and deal with the customer's concerns.  I wonder if, just maybe, there was too much listening to the customer from the solution space, and not the problem space.  (I love that distinction.)

Meanwhile, Steve Vinoski's "Objects as Web Services, Again," is important to our little Numbering Peano agenda.  Of greatest concern to me is Steve's cautionary observation, "in my experience, preaching about the correct way to do things back then wasn't 100% effective, and so I don't hold much hope for preaching about it these days either."

With regard to the problem of allowing objects to be directly exposed as services, Steve has a telling point:

As long as toolkits and standards continue to target the development of web services in languages like Java, C++, and C#, this problem will continue to exist, due to the general mismatch of the abstractions involved. [my emphasis -dh:]

What I think we can contribute here is recognition that there is a mismatch of abstractions and that it matters.  The mismatch is more profound, I am thinking, than simply between programming-language objects and middleware (CORBA or COM) objects.

posted by orcmid at 6/14/2004 09:08:38 AM

Interfaces, Protocol Extensibility, and Versioning

Interfaces, Protocol Extensibility, and Versioning

Dave Orchard's Blog: Protocol Extensibility and Versioning.  Spotted by Danny Ayers, this blog article argues for the essential qualities of a version-1 protocol that alllows for version-n+1 and evolvability.  There are useful links and well-developed arguments.

It will be clear that interface contracts are about protocols and we will need to bother with extensibility and versioning as part of exposing how that matters for Peano Numerals, as with any interfaces that will evolve over time.

I am already fussing with versioning problems in preparing for the next round of examples and moving to demonstration of at least one reference implementation that honors the com.orcmid.LLC.pa.pn.Num interface.  Dave's discussion will be useful as we explore the implementation angle and also look at the impact of interface versioning.

posted by orcmid at 6/14/2004 07:47:51 AM