This turns out not to be the case. There were definitely higher level primitives than Quickdraw available for GUI programming on the Lisa. If you look in the header files for the Apple Lisa Desktop Library Interfaces, you'll see such procedures as:
Dig further and you'll see that Apple had the Lisa Toolkit, which was what we'd now call a GUI framework, written in an OO variant of Pascal called Lisa Clascal. It had classes called TScrollBar, TImage, TDialogBox, TPaginatedView, and so on.
Actually, C#, C++, and Java's OO systems are not conceptually similar to Smalltalk.
If you want languages that implement an OO system with semantics similar to that of Smalltalk, try Ruby or Objective-C.
All the systems do have inheritance, encapsulation, and polymorphism, yes, but beyond that they differ.
The former systems have very rigid 'static' type systems -- types are determined at compile time, and are verified by the compiler.
Smalltalk-like type systems are much more dynamic. Types, as such, aren't seen as being as important as the kinds of messages an object can receive. These systems have the disadvantage of requiring a small runtime to keep track of what object can receive what messages, but they allow marvelous flexibility, and lend themselves to quite a different style of programming.
It's interesting to note that the generics support that's been added to Java 1.5 is completely unnecessary in a dynamic language like Smalltalk, and, in effect, is an attempt to wallpaper over some of the unnecessary coding that a static type system require.
Actually, it was possible with Color Quickdraw and the Display Manager, which were introduced with System 5.
Just to emphasise this, the first Mac that could do this was the Mac II which was introduced in March 1987.
1987. That's 16 years ago folks.
Since then, any Mac that can physically hold more than 1 graphics card has had seamless multi-headed support. That's seamless in the sense of dragging a window so that half of it is on a 24-bit display, and half of it on a black and white display, and things just work. Seamless in the sense of "Holy crap, I've a single 1900x1300 pixel Photoshop window across 4 monitors".
Slashdot Mirror
Forget gzip. You can do SMP or cluster-based bzip though...
http://compression.ca/pbzip2/
http://www.mediawiki.org/wiki/Dbzip2
Yes, but the Intel iMac actually uses an ATI Mobility Radeon X1600...
http://www.apple.com/imac/whatsinside.html
Not quite: there's also things like PhotoBooth and XCode 2.1 which are Universal Binaries. XCode 2.1 (and 2.2) sure counted as upgrades to me...
How about Apple's latest Java 1.5 update?
n tly-starts-sending-out-universal-binaries
http://www.theappleblog.com/2005/11/15/apple-sile
They're not futzing around with ECMAScript; they're implementing parts of ECMA-357.
This specification has been around since June 2004, look it up on http://www.ecma-international.org/
If you download the samples, there's a
To listen to them, do Your favourite ogg player should be able to play the samples.
How long before someone writes a Klingon plugin for it, I wonder?
Actually, C#, C++, and Java's OO systems are not conceptually similar to Smalltalk.
If you want languages that implement an OO system with semantics similar to that of Smalltalk, try Ruby or Objective-C.
All the systems do have inheritance, encapsulation, and polymorphism, yes, but beyond that they differ.
The former systems have very rigid 'static' type systems -- types are determined at compile time, and are verified by the compiler.
Smalltalk-like type systems are much more dynamic. Types, as such, aren't seen as being as important as the kinds of messages an object can receive. These systems have the disadvantage of requiring a small runtime to keep track of what object can receive what messages, but they allow marvelous flexibility, and lend themselves to quite a different style of programming.
It's interesting to note that the generics support that's been added to Java 1.5 is completely unnecessary in a dynamic language like Smalltalk, and, in effect, is an attempt to wallpaper over some of the unnecessary coding that a static type system require.
This is true, and while it may seem a little academic for Linux/x86 users, it's a much bigger problem for people who use Linux on other architectures.
:(
For the likes of Linux/SPARC, Linux/Alpha, and of course Linux/PPC, 'no source' translates back to 'no driver'
Actually, it was possible with Color Quickdraw and the Display Manager, which were introduced with System 5.
Just to emphasise this, the first Mac that could do this was the Mac II which was introduced in March 1987.
1987. That's 16 years ago folks.
Since then, any Mac that can physically hold more than 1 graphics card has had seamless multi-headed support. That's seamless in the sense of dragging a window so that half of it is on a 24-bit display, and half of it on a black and white display, and things just work. Seamless in the sense of "Holy crap, I've a single 1900x1300 pixel Photoshop window across 4 monitors".