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
"External" Interface Contracts
Interfaces, Protocol Extensibility, and Versioning
A Fine Kettle of Fish, indeed.
What Is a Model?
A Fine Kettle of Fish
Numbering Peano: Annotated
Annotating Peano Numbers

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

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