Slashdot Mirror
Adam Fedor of GNUstep Says Stuff
JgiSaw writes "GNUstep provides an Object-Oriented application development framework and tool set for use on a wide variety of computer platforms. It is based on the original OpenStep specification provided by NeXT, Inc. (now owned by Apple and endorced into MacOSX). OSNews is hosting an interview with Adam Fedor, of the GNUstep project, where Adam mentions among others that GnuStep has support for the MacOSX API too, which will make porting MacOSX applications to Linux much easier."
Its kind of cool that it supports the OS X API, but how useful is that in practice? There's hardly any apps that use the OS X APIs right now, and of the ones that exist the developers haven't really shown much interest in supporting Linux...
I haven't used GNUStep recently, but I can tell you that, unlike KDE or GNOME, GNUStep has the capability to bring real applications to linux land.
There are a lot of NeXT developers who would love to port their applications. It would have been a real coupe if GNUStep was ready for prime time before OS X, but, oh well.
My only concern over it was that it used that dog display ghostscript. If you use Solaris, the Sun XWindow server has builtin support for display postscript. It's too bad the Open Source community has a "{XWindows|Display Ghostscript | | etc} sucks, but it's good enough, so why try to build a replacement" mentality. Fortunately, there are people like Adam who say "Fuck that, I don;t want to wallow in mediocracy".
Long live GNUStep!!
Objective C (especially used with the NeXTStep/OpenStep API) does make coding a breeze. The OOPness is more similar to java than C++ (actually, it's more similar to smalltalk, since that's what it's based on).
There are still a number of Next and Former NeXT developers who can tell you how elegant it is.
How does this graphics portion of the API compare to MFC?
I'm not a strong GUI programmer, but I've heard people say that MFC is more robust and powerful than the APIs we have in Linux. But I've also heard people rave about programming NeXT.
Is anyone here able to put ideology aside and give a comparison based on real experience?
One thing was done real well. Principle of least astonishment. You were never surprised (or angered) by the way a method call behaved. Everything acted exactly how you would expect it.
This may be technically true, there are some very nice Mac OSX only apps that although not 'big name' are none the less quite nice. The products at Omnigroup are all nice. Stone Studios products are nice but they could use a nice how to book.
On the near horizon, Adobe Illustrator 10 and Quark 5 are nearing release (both demonstrated at MWNY in July) and they are both, to the best of my knowledge, Cocoa native. They both look VERY, VERY cool.
Office for OSX will also be Cocoa native... not that MS will want to empower Linux, but I believe that MS departments will go for profit where ever it is found... Just look at the Mac market back around 96 when every was SURE that the Mac was dead... MS releases a PPC native Office, mainly because Office was pulling in about 400 Million a year on the Mac way back then.
I think the could only be good for Linux... it will hopefully be good for the Mac OSX community. Tools written here will be very portable to the Mac.
Now if Apple was REALLY smart (hey, they could be once or twice a decade), they would support this project in a big way and they would fund the porting of their _very_ nice free development enviornment to Linux... perhaps built on this foundation.
Apple, you could gain HUGE amounts of respect in the linux community by doing this. You will also gain access to more industrial strength Linux tools for OSX, an OS that will be sound at release 10.1 but which will still be in desperate need of diverse apps.
Steven (stupid Ffakr)
I'm not feeling witty so bite me
I would like to know if there are any IP issues the GNUStep have had, or will have to deal with?
I remember watching the development of GNUStep from back when I just started using Linux (95? 96?). It seems to be a project that has been slowly in development for years now, yet unfortunately hampered by a lack of support from the OSS community.
I wouldn't blame anyone, though. Most people are not familiar or even interested in the NeXTStep/OpenStep platform. The technology is definately strange, based on Objective-C and a postscript-based rendering engine, but this platform was (is) years ahead of its time.
I have OpenStep 4.2 for intel, and it is probably the coolest OS ever. At one point I got a copy of an early OS X beta for intel, and it was basically OpenStep 4.2 recompiled with a Macos-looking widget set and a menubar instead of the Wharf ("Dock" in WindowMaker land). The look and feel of OpenStep is far and beyond any UNIX or Windows desktop in terms of sheer quality and useability (many believe the Windows widget set is imitative of the NeXT look to the point that NeXT could have sued Microsoft).
It is sad to think that if Redhat decided to throw its weight behind GNUStep instead of GNOME, we probably would have had a full-fledged, slick NeXTStep/OpenStep/Macos X clone right now layered on top of any UNIX kernel. This is just too bad. I think pretty soon I will reinstall OpenStep 4.2 on my Intel box, and I'm definately investing in one of those G4's to find out what those old NeXT developers (considered some of the most innovative and talented GUI developers in the world) have been up to.
Yes, because C++ is a Turing-complete programming language, you can do anything with C++ that you can with Objective-C.
However, to anyone who has used Obj-C and NeXTSTEP in any depth, your question sounds much like "What's so great about having sex? I can have an orgasm by jerking off, can't I?"
Let me put it this way: in 1989, I knew the Mac *cold*. I switched to NeXT, and it took me about one month to be as productive using the AppKit as I had ever been on the Mac. Within the year, I was at least three times as fast doing any given task.
The only development environment that ever arguably equalled NeXTSTEP for productivity was Smalltalk.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
A few months ago, a demo of QT for OS X was released, I was very intersted, so I tried it out. Honnestly the thing was rather dissapointing, at least for me.
Unfortunately, you're not looking towards the future: Adobe, Microsoft, and several other major software manufacturers have promised versions of their major titles for the Cocoa API, several of which have been demonstrated live in the last few months. I encourage you to look at both Microsoft's Macintosh pages, as well as Adobe's web site.
I'm not sure what you'd be referring to. The products that Microsoft has announced for Mac OS X -- Office 10 (for Mac OS X only, not Mac OS 9/8) and Explorer -- are both Carbon apps. They have not demoed or confirmed any Cocoa apps in the works. They may eventually, but it's debatable if there is reason to do so anytime soon if Apple continues to improve Carbon. The story is pretty much the same on Adobe's side. They have demoed InDesign, Illustrator, GoLive and some others. They have also release a native version of Acrobat. But these are all Carbon apps. They have not talked about any Cocoa apps.
Aside from the fact that it is generally easier to port existing large Mac apps to Carbon than rewrite them in Cocoa, Micrsoft and Adobe still have the vast majority of their customers on Mac OS 9/8. They are probably not too keen to do massive forks at this point. The fact that the Mac OS Toolbox and Carbon APIs are similar makes it fiscally feasible to address both Mac OS 9 and Mac OS X markets.
There are two ways to use Carbon. You can create a single Carbon binary that executes on both Mac OS 9/8 (old technology) and Mac OS X (Mach/BSD). However, this somewhat limits how much you can do on the Mac OS X side. The other option is to use Carbon only as a porting bridge. You don't end up with two separate binaries (one for OS9, one for OSX), but you still get two relatively similar code bases with similar API calls. This is what many developers have opted to do since it allows them to build a better Mac OS X app without having to completely rewrite their software. Microsoft is currently doing this with Explorer.
There actually is a third reason to use Carbon -- it's a C/C++ framework. Maya opted to use Carbon for this reason. Cocoa apps can currently only be written in Objective-C and Java. There is talk about resurrecting Objective-C++, though.
Carbon and Cocoa apps can look essentially identical to the untrained eye. Both make calls to the same core frameworks. They both provide protected memory spaces, preemptive multitasking, and access to Quartz. They are peers in many ways. "Classic" is the compatibility environment in which a Mac OS 9 virtual machine is launched to run old Mac apps that have not been ported to either of the new APIs. While Cocoa and Classic apps use Aqua UI widgets, Classic apps do not. They generally have the grey chizeled look of Mac OS 9.
By the way -- the Finder, Mac OS X's file manager/shell is written in Carbon, as is the event manager. And based on Apple's statements, it looks like they have done a lot of work on Carbon for the emminent Mac OS X 10.1 release. Several upcoming Carbon Mac OS X apps require 10.1.
- Scott
Scott Stevenson
Tree House Ideas
Remember, Mac OS X is essentially NeXTSTEP
Perhaps if you look at it in terms of only Mach/BSD and Cocoa. There is tons of stuff there that was never in NeXT, though: Carbon, Quartz, system-level QuickTime usage, AppleScript/AppleEvents, I/O Kit, Mac OS 9 compatibility.
It borrows some lower-level from NextStep, some higher level stuff from Mac OS, and makes something brand new. GNUStep apparently only attempts to address the NeXT side of the world, but a lot of the mainstream items will make heavy use of the Mac side of things.
- Scott
Scott Stevenson
Tree House Ideas
I've posted similar messages in this topic, but wanted to get it up to a higher level to resolve a lot of the confusion...
/.ers shouldn't let their expectations get out of hand. At the moment, GNUStep is no more helpful in getting MS Office to Linux than is Mac OS X's use of BSD libraries.
Even in a finished state, GNUStep does not do as much to get apps to Linux as some people seem to think Or, at least, not the apps they have in mind. If you're at all familiar with Mac OS X development, you know that there are four APIs that the system considers "native": Cocoa, Carbon, Java and BSD. Any program written to these APIs receives it own 2GB of protected address space (yes, even individual Java apps), as well other modern OS features. Classic is the Mac OS 9/8 compatibility environment. Sort of an "emulator on steroids," to use a cliche.
GNUStep provides a implementation of the OpenStep spec, which is what Cocoa is based on. Theoretically, this means that Mac OS X apps written in Cocoa can be easily ported. But the vast majority of the brand name apps have been or are being ported to Mac OS X are written in Carbon. The long list of Carbon apps includes:
- Office
- Explorer
- Macromedia Freehand
- Acrobat
- GoLive
- Illustrator
- Bryce
- Corel Knockout
- Corel Draw
- Painter (Corel/MetaCreation)
- Maya
- Quicken
- Netscape
Quite a few people have posted messages to this topic mistakeningly claiming some Carbon apps were actually Cocoa apps, including Office. I'm not sure what would have caused this confusion. Part of the problem may be that you cannot tell the difference between a Cocoa app and and a Carbon app unless you really know what to look for. Both use Aqua UI widgets. Some individuals might also be making the assumption that if an app is "Mac OS X only" (meaning does not run on Mac OS 9), then it must be written in Cocoa, which is not true.
So why write in Carbon, you ask?
Most existing Mac developers port apps to Carbon because it's easier than a complete rewrite in Cocoa. It also means that developers can keep reasonably similar (in some cases, identical) code bases for both Mac OS X and Mac OS 9. This is important because most of their customers will be on Mac OS 9 until the transition is complete. Alias|Wavefront was not porting an existing Mac app, but opted to use Carbon for Maya because they have existing C++ code (and developers?) they want to use. Cocoa frameworks can currently only be accessed from Objective-C or Java.
Over time, you may see developers do rewrites in Cocoa, because in many ways it is a better environment. Ther resurrection of Objective-C++ would probably help this. But the more Apple does to improve and refine Carbon, the less immediate the need will be to do rewrites in Cocoa.
So that's that. Now, getting back to GNUStep....
From this interview, it sounds like the GNUStep folks have the Foundation side of Cocoa pretty well in hand, but it looks like AppKit (all of the GUI stuff) is not done. But even after they finish everything that has been around since OpenStep, I'm curious how they're going to resolve all sorts of new stuff. Specifically, I'm thinking about things like QuickTime (used for much more than video), Quartz (transparency/compositing, PDF generation/manipulation, text rendering), and even stuff like AppleScript/Apple Events. These are things that Mac OS X developers are and will be using, but I can't imagine they're going to be very easily to implement from scratch on the GNUStep side. I understand that there are perhaps counterparts, but how comparable will they be? I'm genuinely curious about this.
I praise Adam and his colleagues for their efforts. But at the same time,
- Scott
Scott Stevenson
Tree House Ideas
Also, in my programming, collections are typically heterogeneous. With templates you'd have to have a common base class with virtual methods, and you'd no longer have much of an advantage over Objective C, while having none of the convenience.
I think the dynamically-typed languages are more true to OO, because objects are defined only by their interfaces. Any object that implements a sufficient interface can be used in that context. You can do great things with that.
Others might feel that message-passing is a more appropriate term for the type of OO in Objective C. However you say it, there's something there that Objective C does that C++ doesn't -- even if it might be possible under C++, people just don't.
Well, there are Objective C applications of appreciable size. There were lots of applications for NextStep -- web browsers, 3D rendering, etc. Not all of these applications are dead. They should provide significant fodder for comparison, should someone choose to do so.From a reductivist point of view, Objective C can be as efficient as C++ or C. With clever programming you can use dynamic typing to your advantage, because the method lookup can take the place of logic statements. I know this is very common in Smalltalk. But unlike Smalltalk (or Java), you can write Objective C with the inner loops (where performance matters) in C.
I thought NextStep ran fairly well on the m68k workstations I used. It wasn't blindingly fast, but like I said, it was a m68k processor.
Large systems can potentially be significantly faster in Objective C, because of the generality of the object model and the richness of the foundation library.
"Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."
I think Objective C has a relation to Common Lisp there (if not quite as complete -- thankfully!), and C++ is still stuck with C or Fortran -- good base libraries have been very slow in coming (though they do appear to be coming along)