PowerPC, Taligent(Pink), and NeXT
mrot...@data.acs.calpoly.edu
which discusses the Power PC. The article says (or so I was told)
that early (beta?) versions of the chip are already out, and that
Taligent and entry level versions of the chip will be out at the end
of 93'. The article also stated that the system would run all Mac
programs, and all DOS programs in addition to its own software. Mac
and DOS software is supposed to run with out any noticeable downgrade
in performance.
This prompted me to have the following thoughts. I doubt that, in
the rush to market, IBM/Apple will produce a product superior to, or
even equal to, NeXTstep. Also, I feel it would be good for the
industry to diverge from the present course and adopt a new standard
platform. It is always good for a society to under go occasional
upheavels of the establishment. Now I think, and I'd guess most of
you do also, that NeXTstep would make a good replacement for DOS/Mac
OS. The problem as I see it is that if Taligent does what they say
it will, then most likely people will leave DOS/Mac OS when they buy
a new machine and move to Taligent. No questions asked, clean and
simple. That is unless there is a clear superior alternative. If
NeXT wishes to capture the PC market (I guess it is possible that
they don't want to) then the following should let them do it: port
NeXTstep to the Power PC before Taligent is released, bundle full Mac
and IBM emulators or make sure that they are available from 3rd
parties at a reasonable price, do all this 6 months before the
release of Taligent. With a 6 month head start and equivalency or
superiority in all areas NeXT should have a fairly good chance of
winning out over Taligent. Of course if Taligent does turn out to be
better than NeXTstep...well we can cross that bridge when we come to
it.
I have to go buy that mag. and read the article myself, but I was
wondering what everyone's thoughts were on this. Do you think those
steps will give NeXT the advantage? Does NeXT even need to do those
things? Does NeXT have no chance at all?
Mont
Satisfaction only exists in the future!
M Carling
mrot...@DATA.ACS.CALPOLY.EDU writes:
[some thoughtful speculation about Taligent and NeXT deleted]>
> wondering what everyone's thoughts were on this. Do you think those
> steps will give NeXT the advantage? Does NeXT even need to do those
> things? Does NeXT have no chance at all?
Apparantly, they still can't agree on anyone to run Taligent. NeXT also
reportedly has hired away their best programmer. Taligent is also a monster,
reportedly having something on the order of 2,000 different objects.
M Carling
David Pollak
> they don't want to) then the following should let them do it: port
> NeXTstep to the Power PC before Taligent is released, bundle full Mac
> and IBM emulators or make sure that they are available from 3rd
> parties at a reasonable price, do all this 6 months before the
> release of Taligent
There is a company called Quorum Software Systems that has produces software
that will allow a Mac program to be run on a workstation either as an
interpreted 68K program or recompiled and linked with a special library (makes
porting programs from the Mac a re-compile for the developer.) It is available
for Sun, SGI, R/S6000, but not NeXT. There are lots of rumors floating around
as to why it's not available for the NeXT. I doubt that the management at NeXT
would "lower" themselves to allow Mac programs to be run on or ported to their
machine. NeXT has a wonderful vision for the forest, but I don't think they
see the tree that is about to fall on their head.
--
David Pollak - d...@athena.com - NeXTMail Compliant
Attorney at Law, Director, Boston Computer Society, NeXT Group,
Feeder of the Bears, Athena Design, Inc.
William J. Edney
writes:
> for Sun, SGI, R/S6000, but not NeXT. There are lots of rumors floating
around
> as to why it's not available for the NeXT. I doubt that the management
at NeXT
> would "lower" themselves to allow Mac programs to be run on or ported to
their
> machine. NeXT has a wonderful vision for the forest, but I don't think
they
> see the tree that is about to fall on their head.
David -
Well, ARDI, out of Albuquerque N.M has a full-blown Macintosh emulator
running on the NeXT (called Executor). No recompiles, no nothing. Just pop
a Mac floppy in and run the program. I know Cliff Matthews and he said
that NeXT has been very supportive of his efforts.
BTW, I have a copy of Executor (a full blown Mac emulator for *$85.00*)
and it really works!!
--
- Bill Edney, Los Alamos National Laboratory
- bed...@monolith.lanl.gov (NeXTmail accepted and encouraged)
"Automatic garbage collection!" - yelled by Steve Jobs, going
down an "up" escalator at NeXTworld Expo, Jan. 23, 1992
Jim Cooper
>
> Apparantly, they still can't agree on anyone to run Taligent. NeXT also
> reportedly has hired away their best programmer. Taligent is also a monster,
> reportedly having something on the order of 2,000 different objects.
>
> M Carling
>
I really don't have any idea about any details about Taligent, but whether
it's 2,000, more than that or less, what M is referring to are classes,
not objects. Classes are program behaviors defined in programming code,
objects are hunks of memory in which that code lives when a program is run.
The two aren't the same. If there are indeed 2000 classes, there will
probably be considerably more objects existing when the system is running.
Jim Cooper
disclaimer: I see nothing, I hear nothing, I know nothing
M Carling
> I really don't have any idea about any details about Taligent, but whether
> it's 2,000, more than that or less, what M is referring to are classes,
> not objects. Classes are program behaviors defined in programming code,
> objects are hunks of memory in which that code lives when a program is run.
> The two aren't the same. If there are indeed 2000 classes, there will
> probably be considerably more objects existing when the system is running.
True. I spaced.
M Carling
Scott Wisdom
> it's 2,000, more than that or less, what M is referring to are classes,
> not objects. Classes are program behaviors defined in programming code,
> objects are hunks of memory in which that code lives when a program is run.
> The two aren't the same. If there are indeed 2000 classes, there will
> probably be considerably more objects existing when the system is running.
However it's worth noting that with this many classes available, it's quite
possible that many of the classes will be instantiated only at certain times. A
number of core classes will have objects alive at all times, but many classes
may just be there for support in certain circumstances. It is probably safe to
assume, for example, that many NeXTStations out there have never instantiated
MusicKit classes, but they're there if needed (with OS <= 2.x, of course).
> Jim Cooper
Scott Wisdom
wis...@geom.umn.edu
Andrew Loewenstern
I think what is happening is that they are creating either a class or an
abstract super-class for every teeny-weeny little bit of behaviour they add to
a class... For instance, instead of having one ScrollView class with
setHorizScrollerRequired: and setVertScrollerRequired: you have an abstract
superclass called ScrollView, two sub-classes HorizScrollView and
VertScrollView, and then a HorizAndAVertScrollView that is a multiple inheritor
of VertScrollView and HorizScrollView. The advantage of this is that you can
either instantiate precisely the behavior you want with little initialization
and when you create your own class, you can mix and match only the stuff you
need. The disadvantage, I suppose, is that you can run into heavy-duty
problems at runtime when you want to change something unless you use a big
complicated class in first-place.
2000 classes sure does sound like a bit too much. Heck there are only what 64
classes in the AppKit?
Although I'm sure they had some excellent reasons to take this approach, I
prefer the simplicity of the AppKit. Because when I want a ScrollView, damnit,
I want a ScrollView and not a
HorizScrollerBezeledWhiteBackgroundNOTAutoDisplayPaisleySwirledScrollViewFromHE
LL.......
andrew
--
and...@cubetech.com
Andrew Loewenstern | "I shall not equate bit-mapped
Cube Technologies, Inc. | text with reality."
Ronald C.F. Antony
>2000 classes sure does sound like a bit too much. Heck there are only what 64
>classes in the AppKit?
>
>Although I'm sure they had some excellent reasons to take this approach, I
>prefer the simplicity of the AppKit. Because when I want a ScrollView, damnit,
>I want a ScrollView and not a
>HorizScrollerBezeledWhiteBackgroundNOTAutoDisplayPaisleySwirledScrollViewFromHE
>LL.......
I would bet the excellent reason is called C++. And that is probably
also the excellent reason why NeXT chose Objective-C and not C++.
C++ is a nice code organizer, but it has few of the real niceties of
OOP. (such as run-time flexibilty, polymorphism, etc.)
In exchange for that it is faster in theory. (Well, if you have to
swap to access one of your zillion classes you might loose even if in
principle you are faster than the guys using only 100 flexible
classes)
Ronald
------------------------------------------------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | r...@cs.brown.edu or ant...@browncog.bitnet
Sean Eric Fagan
>I would bet the excellent reason is called C++.
I doubt it. I suspect it's because they simply have put a lot more in
there, including (I suspect) all of the OS primitive classes. (Remember,
every 'struct' is a class!)
--
Sean Eric Fagan | "One form to rule them all, one form to find them, one
s...@kithrup.COM | form to bring them all and in the darkness rewrite the
-----------------+ hell out of them" -- sendmail ruleset 3 comment from DEC.
Any opinions expressed are my own, and generally unpopular with others.
Andrew Loewenstern
> swap to access one of your zillion classes you might loose even if in
> principle you are faster than the guys using only 100 flexible
> classes)
I don't even know if that's true anymore. In one of the performance tuning
sessions the Expo, NeXT's resident bit-basher said the obj-c message calls have
been optimized to something like 7 instructions in 12 clock-cycles. That's
pretty damn fast! Not as fast as a straight function call, but still pretty
fast. It really doesn't add up to a whole unless you call are trying to
call a method or a group of methods over and over and over very quickly in a
loop....
Andrew Loewenstern
> In article <1992Feb16.1...@cs.brown.edu> r...@cs.brown.edu (Ronald
C.F. Antony) writes:
> >I would bet the excellent reason is called C++.
>
> I doubt it. I suspect it's because they simply have put a lot more in
> there, including (I suspect) all of the OS primitive classes. (Remember,
> every 'struct' is a class!)
Yes, I think every struct and typedef will be a class. Imagine the overhead!!!
And I do think there is a *lot* of overhead. Reports from people who have seen
Pink on the RS/6000 under non-disclose say that it works, but it's slow and
it's not that clean yet.... We'll see.
Kelly Anderson
> In article <1992Feb16....@kithrup.COM> s...@kithrup.COM (Sean Eric
> Fagan) writes:
> > In article <1992Feb16.1...@cs.brown.edu> r...@cs.brown.edu (Ronald
> C.F. Antony) writes:
> > >I would bet the excellent reason is called C++.
> >
> > I doubt it. I suspect it's because they simply have put a lot more in
> > there, including (I suspect) all of the OS primitive classes. (Remember,
> > every 'struct' is a class!)
>
> Yes, I think every struct and typedef will be a class. Imagine the
overhead!!!
> And I do think there is a *lot* of overhead. Reports from people who have
seen
> Pink on the RS/6000 under non-disclose say that it works, but it's slow and
> it's not that clean yet.... We'll see.
Well, Pink or Taligent isn't suppose to be done for several years yet.
With 2000 classes, I can see why. I don't have any problem specifically
with having a system with 2000 classes. The overhead of an additional class
in c++ is not so awful. But how could you ever document, or become familiar
with such a beast?
Jon Rosen
>>Although I'm sure they had some excellent reasons to take this approach, I
>I would bet the excellent reason is called C++. And that is probably
>also the excellent reason why NeXT chose Objective-C and not C++.
>C++ is a nice code organizer, but it has few of the real niceties of
>OOP. (such as run-time flexibilty, polymorphism, etc.)
I think it is too complex and because they got the default wrong...
EVERY method should be virtual UNLESS you ask for STATIC binding and
typing)... However, I do not think it is right to bandy about
misinformation...
If methods are declared VIRTUAL in C++ (and I usually declare ALL my
methods virtual), then those methods can be messaged by an object
whose type is a class at a high level in the class hierarchy even
though the actual underlying object is a more specific subclass
and the appropriate subclass's version of that method will be called.
This is polymorphism, no doubt. This does NOT work for normal methods
(i.e., non-virtual methods) because the version of the method then
called is ALWAYS the version associated with the class of the object.
Since objects are assignment-compatible if they are of equal or
a derived class, it is relatively straightforward to build lists of
objects of a class like ANIMAL and then run the list sending each
ANIMAL object a GROWL method and if there are several ANIMAL subclasses
called LION, TIGER and BEAR (oh my :-), and each subclass has its
own GROWL method (and the GROWL method has been declared virtual
at the ANIMAL level), the appropriate ANIMAL objects of these different
subclasses will GROWL appropriately. Polymorphism, no question.
It is true that it is not as flexible as Obj-C, but let's be factually
accurate. C++ does indeed support polymorphism. It also supports
what we have come to call run-time binding, at least with respect to
virtual methods.
Jon Rosen
Ronald C.F. Antony
> If methods are declared VIRTUAL in C++ (and I usually declare ALL my
> methods virtual), then those methods can be messaged by an object
> whose type is a class at a high level in the class hierarchy even
> though the actual underlying object is a more specific subclass
> and the appropriate subclass's version of that method will be called.
> This is polymorphism, no doubt. This does NOT work for normal methods
> (i.e., non-virtual methods) because the version of the method then
> called is ALWAYS the version associated with the class of the object.
> Since objects are assignment-compatible if they are of equal or
> a derived class, it is relatively straightforward to build lists of
> objects of a class like ANIMAL and then run the list sending each
> ANIMAL object a GROWL method and if there are several ANIMAL subclasses
> called LION, TIGER and BEAR (oh my :-), and each subclass has its
> own GROWL method (and the GROWL method has been declared virtual
> at the ANIMAL level), the appropriate ANIMAL objects of these different
> subclasses will GROWL appropriately. Polymorphism, no question.
>
> It is true that it is not as flexible as Obj-C, but let's be factually
> accurate. C++ does indeed support polymorphism. It also supports
> what we have come to call run-time binding, at least with respect to
> virtual methods.
Consider the following hierarchy:
aClass
aClassSubclass1
aClassSubclass2
aClassSubclass1Subclass1
aClassSubclass2Subclass1
Now if aClassSubclass1Subclass1 defines a new method with name ADD
and so does aClassSubclass2Subclass1 but neither aClass nor
aClassSubclass1 nor aClassSubclass2 do, then is is not possible to use
ADD on an object that could either be of class
aClassSubclass1Subclass1 or of class aClassSubclass2Subclass1.
At least last time I checked that was impossible. That is what I call
true polymorphism. Now if that should be possible with newer versions
of C++ I'd be glad to hear about it. I stoped following C++ when I
knew these things were not possible, so it might be it changed.
In any case Objective-C runs circles around C++ in flexibility. (Yes,
I hear some ppl scream about type checking etc. but I couldn't care
less)
Sean Eric Fagan
>aClass
>aClassSubclass1
>aClassSubclass2
>aClassSubclass1Subclass1
>aClassSubclass2Subclass1
>
>Now if aClassSubclass1Subclass1 defines a new method with name ADD
>and so does aClassSubclass2Subclass1 but neither aClass nor
>aClassSubclass1 nor aClassSubclass2 do, then is is not possible to use
>ADD on an object that could either be of class
>aClassSubclass1Subclass1 or of class aClassSubclass2Subclass1.
That'd be real neat, considering it's entirely possible that the ADD member
function requires support that just isn't aClass or aClassSubclass1. What
would you *expect* it to mean?
Bob Congdon
> Well, Pink or Taligent isn't suppose to be done for several years yet.
> With 2000 classes, I can see why. I don't have any problem specifically
> with having a system with 2000 classes. The overhead of an additional class
> in c++ is not so awful. But how could you ever document, or become familiar
> with such a beast?
Why don't we try to put this into perspective: The 2000 classes are for the
entire Pink operating system, right? As a rough comparison to NextStep 2.0 look
look at all of the header files under /usr/include. There are something like
700 structs and 300 Objective-C classes (including the musickit) -- and that's
just what's exposed for *public* interfaces. It certainly wouldn't be
surprising if the inclusion of all of the private types, ObjC classes, etc. in
the NextStep internals pushed this figure to 2000 or beyond.
More to the point, the total number of classes that Taligent used to implement
the Pink operating system isn't a very meaningful measure of the complexity to
the application programmer . What you should measure is the complexity of the
programmer's interface: What does the application environment expose to the
programmer? How many public classes? How many methods? What's the class
hierarchy look like? How is the whole thing packaged?
The NextStep Appkit may be only 60 or so classes but it's pretty complex. There
are over 2000 public methods in the interface. However, the way in which the
Appkit is packaged, you don't need to worry about a lot of this complexity
unless you want to do something unusual. Next did a great job in packaging.
Possibly meaningless data point: I just did a quick scan of our Improv code
which is a mixture of C++ and Objective-C code. We have approximately 300 C++
classes and 150 Objective-C classes. Improv is a fairly complex application but
by no means as complex as an operating system.
--bob congdon
bcon...@lotatg.lotus.com
Lotus Development Corporation
Cambridge, MA 02142
Disclaimer: Sure, I speak for Lotus. Not!