Slashback: Interoperability, Royalty, Fire

Read on for clarification about the alleged Gnome/KDE collaboration reported a few days ago, which ... ain't. And about the project to put Linux on the Royal DaVinci, which promises slow but steady progress. There's also infernally good news for anyone intrigued by the recent open-source Plan 9 release.

Pardon me, sir, are you in the market for a nice strong bridge? Aaron J. Seigo writes: "A letter from Mosfet can be found at knews.derkarl.org which clearly states the official KDE position regarding the recent "news" with regard to Gnome and KDE getting together on a common component model. Which is: It isn't happening. And for good reason.

KDE2 is in the final stages of preperation, so this is not the time to go messing with the foundations of things. Also, KParts wasn't designed on a whim. The KDE team put a lot of thought into it and came up with something that has some very real benefits to it (speed/overhead/etc). While interoperability would be nice, don't expect it on the component level just yet. Be happy with drag 'n drop and the like. For now."

Fair enough. Also on the KDE front, Joseph points you to knews.derkarl.org, which seems like a useful one for anyone looking for KDE updates.

Will a Linux PDA become their strong suit? jsinnema writes "News on the Linux Powered Royal daVinci from Wayland Bruns, CEO/CTO/Chief Geek CompanionLink Software at PDA Buzz Royal: 'Unfortunately, development is not on the timeline originally hoped. What's shaping out is two 16MB ROM/16MB Ram units, one 4 color grayscale for a low price, the other full color for a higher price. Size and weight are about the same as a Palm III. The color unit will have a flash slot.' and
'One of the interesting aspects of the project is that this is the first time we can directly compare performance of a particular app on both PC and PDA. I'm happy to report the PDA units are surprisingly powerful, except to note that memory access is relatively slow.'"

It sure would be neat if Linux becomes the default OS for palm-top computing; will Royal's project, though, stand a chance against the flashier ones which keep peeking like Monty Python animation over the horizon?

I'm sorry, but I'll have to call you back after I set my computer on fire. rpeppe writes "those who were intrigued by the Plan 9 release but don't have the appropriate hardware, or in fact anyone interested in new languages and OS's should be interested in the following:

vita nuova has released a new edition of the Inferno OS, source code and all, under a new licence, which allows distribution of core OS source code to inferno subscribers only, but unencumbered personal and commercial use of the binaries and the rest of the source code (including a javascript capable Web browser).

inferno is a cousin to Plan 9, but includes a virtual machine and a new language, limbo, and can run hosted under linux, free bsd, windows and other OS's, as well as natively on x86, ARM, MIPS, 68000, 68020 processors. because the whole operating system is virtualised, programs written for inferno are completely portable, something it would be difficult to say about java, for instance.

the language, limbo, deserves some attention - it's C-like, and OO in the deeper sense, but avoids the inheritance pitfalls that languages like java fall into. it's a joy to write in.

in my opinion, inferno was the coolest thing ever to have come out of bell labs CSRG - and we've now got exclusive rights to it, and intend to make as much of this excellent technology as we can. i hope others will too!"

Comments

Re:Oh no..Plan 9

[td]

Uhh, Plan 9 is an operating system, not an
application -- there's no chance that it would
appear in anybody's process tables.

I just grepped my copy, and the string
`plan9.conf' appears nowhere in the
Plan 9 distribution.

The `original incantation' [sic] of Plan 9 was
Plan 9 -- it was a new system from the ground
up, developed in the Computing Science
Research Center at Bell Labs, not by any bunch
of Deccies working spare time. (Dave Presotto,
largely responsible for Plan 9 networking, worked
at DEC once, but that was before he went to grad
school, I believe.)

I speak having worked on Plan 9 at Bell
Labs for 6 years (and I have the Bowling
Shirt to prove it.) Among other things,
I wrote the shell and a whole load of
graphics junk.

Joy In Limbo?

[djKing]

implement Command;

include "sys.m";
include "draw.m";
sys: Sys;

Command: module
{
init: fn (ctxt: ref Draw->Context, argv: list of string);
};

# The canonical "Hello world" program, enhanced
init(ctxt: ref Draw->Context, argv: list of String)
{
sys = load Sys Sys->PATH;
sys->print("hello world\n");
for (; argv!=nil; argv = tl argv)
sys->print("%s ", hd argv);
sys->print("\n");
}

yeah, I'm sure glad limbo avoids those obvious Java pitfalls. Hello World in limbo is such a joy. I'm convinced.

Inferno/Plan9

[bkrog]

Few people would think it reasonable to write to the editor of a literary magazine, commenting on and expressing opinions concerning a book which they have not read, yet several contributors have no compunctions about expressing their opinions about both Plan 9 and Inferno, despite an admitted lack of familiarity with either. At the very least, posters of 'opinions' should read some of the documents freely available from Bell Labs prior to commenting.

Else it's entirely possible that one might later come to regret snide comments made concerning the work of various members of the ACM, Bell Lab's Fellows, recipients of the National Medal of Technology, etc.

Contributors to the Inferno/Plan 9 project include Rob Pike, Phil Winterbottom, Ken Thompson, Dennis Ritchie and others.

I think perhaps their concept of 'peer review' for their work extends somewhat beyond the constituency of /.

Thoughts on DirectX

[spoonboy42]

Just a few thoughts on your comment.

First, even if DirectX were ported, you wouldn't be able to just install windows games straight to linux, as they depend on other win32 APIs and libraries as well (although combining WINE with the DirectX port might allow this to be achieved).

As far as OpenGL vs. DirectX, I tend to lean towards OpenGL. It's an open standard, and there are (mostly) compatible implementations offered by SGI, Microsoft, and a host of others (including the open-source MESA). OpenGL was designed with portability in mind, whereas DirectX was created to one-up Apple when quicktime was the hot multimedia format. DirectX is just barely portable to other versions of windows besides 9X (they had to redesign NT's hardware interface layer to make it work in Win2K), let alone UNIX/X11.

OpenGL does default to much higher precision than DirectX, which makes it theoretically slower, but in practice it bests the other API considerably when weilded by a good 3D programmer. Also, let's not forget that OpenGL was originally concieved by SGI, and the feature-sets of SGI chips tend to be a few years ahead of everybody else's. Therefore, "new" features like hardware T&L are already supported by OpenGL and used by all existing GL applications, whereas DirectX has to catch up to the hardware. In fact, even when upgrading to a new version of DirectX, old apps don't benefit from new hardware features.

I've had my current debian installation for more than a year, and I've never had to upgrade MESA. Windows folks haven't needed a GL upgrade since it was first included by default in a service release to Win95, whereas someone with the same version of windows has probably been through at least 4 upgrades to DirectX.

Re:uh. (Explanation)

[Anonymous Coward]

(I do OO dev since 1991. I love this, and I pretty know what I am talking about).

Inheritance lead to problems because it is easily messed and very difficult to undo.

There is a design time inheritance (ie: B is-a A), and implementation time inheritance (ie: we are going to reuse the implementation of A to build B).

Pitfall of inheritance is that it is very inflexible. During the life of a system, requirements change slowly, design mistake have to be corrected, implementation improve. When things get so wrong, that the implemented inheritance is bad, splitting the classes, changing hierarchy, etc, etc, have a deep impact on what is already produced. (In one word, evolution is easy, until you hit the wall-of-brick of the choosed hierarchy and the pain starts).

The fragile-base-class (in general sense, not in C++ only sense) is also a problem. It means that changing superclass implementation can have vast impacts to subclasses. This often lead to frozen superclasses (ie: don't change it, too much people rely on its particular quirks)

Another problem with inheritance is that it is unknown how far to go with it. Grab any textbook on OO, read the example, and try to understand if the hierarchy is really good. This depends on the problem at hand, which sometimes is not known. But OO proponents like to ignore those issues and present things have if there was single true way.

Stupid example:

Shape -> Polygon -> Square
-> Triangle
-> Line
-> Polygon
-> Circle
-> Point

Is this right ? Wrong ? Isn't Point a zero radius circle ? Line and Point have no surface, so maybe there should be closed/non-closed shapes somewere ?

The answer is that there is no right/wrong. It depends on how it will be used. There is no a single *right* inheritance. But a choosen inheritance somewhat constraint the way we see things.

Java's interfaces is a try to get rid of those problem, but is IMHO a short shoot.

Dynamic langages are less sensitives to those problems. Check Objective-C, Smalltalk or TOM http://www.gerbil.org for more insight on this.

When all you have is a hammer, every problem looks like nails.
When all you have is inheritance, every design is a hierarchy.

For fun design failures, take a look at Swing/AWT integration. When you start to grasp the mess (Graphics/Graphics2D, paint() overload, and casts), it is really funny to see the nightmare coming on the road.

Cheers,

--fred

Re:uh.

[rpeppe]

by "inheritance pitfalls" i meant several things. probably near the top of the list is the fact that in programs that extensively use inheritance, you tend to get interdependency of classes where there is no need for such interdependency. this IMHO is directly counter to the basic tenets of OO programming which call for encapsulation of objects and their state towards the end of re-usable code and software.

if i use a class C which inherits from B which inherits from A, i'm dependent not only on C (which is the object i want to use) but also, unintentionally on B and A. If C wants to use a different superclass, for implementation reasons, then i have to change or recompile a lot of code that relies on it.

here's a little extract from a recent article in IEEE's "Computer" journal [April 2000]:

Subclasses are descendents of other defined classes. Java and other object-oriented langages let you substitute a subclass object for a superclass object. However, you must satisfy certain properties to guarantee that your substitution is safe. One safe substitution is when the subclass is a specialisation of the superclass. For example, a Cartesian point with color attributes can be a specialisation of a Cartesian point without color. You can then substitute a colored point because any behaviour of plain points also applies to colored points

Problems can occur when a subclass is not a true specialisation of its superclass. Consider the java.util.Stack class, which is part of the java.util package. Class java.util.Stack is a subclass of java.util.Vector. Stack defines common stack methods such as push(), pop(), and peek(). However, because Stack is a subclass of Vector, it inherits all the methods Vector defines. Thus, you can supply a Stack object wherever the program specifies a Vector object. A program can insert or delete elements at specified locations in a Stack object using Vector's insertElementAt or removeElementAt methods. It can even use Vector's removeElement method to remove a specified element from a Stack object without regard to the element's position on the stack.

Consequently the java.util.Stack can exhibit behaviour that is not consistent with the notion of a stack as a last-in, first-out entity. In addition, a program can access all the Vector operations on Stack objects directly when the Stack objects are not being substituted for Vector operations.

A stack is not a specialised vector, and it should not inherit vector operations. Instead, a vector should be a hidden, private representation of a stack. Stack objects cannot then export innappropriate vector operations. This preferred design uses aggregation, which lets you use inheritance and polymorphism to replace the vector representation with alternative implementations. If you use inheritance properly, the design will be more flexible and efficient.

[my italics]. It seems to me if it's possible to design a language which doesn't allow such problems, then it would be a good thing. i have yet to be convinced that inheritance is a Good Thing. i used Objective-C (java's object model is partially based on objective-c's) under NeXTstep for 7 years, and encountered all the problems mentioned. code reuse, like hardware component reuse can only come about by minimising the breadth of interconnection between code modules. inheritance does not help us do that.

plus there's the fact that code using inheritance is hard to read, because you're never quite certain which level of a class hierarchy is implementing a method... until you browse the hierarchy. so much for readable code.