Slashdot Mirror
10 Years of OpenStep
tarzeau writes "Today, the OpenStep API celebrates its 10th anniversary. What started out as a joint adventure of NeXT and SUN to define an application development standard that would run on all machines, making 'write once, compile everywhere' a reality, is still unfolding within the vivid and active community of GNUstep, old NeXT and Apple lovers.
The magic 10 appears in GNUstep's current 1.10.x release and in Apple's Mac OS X 'Cocoa' release. Programmers worldwide can develop their programs on Mac OS, Linux, the BSDs, Solaris, and with a couple of hurdles -- even on Windows. This solid and well-defined standard is reaching out to the world of software development, slowly but surely.
Program your applications in days or weeks, rather than years or never. Use the advanced API of a development framework that hasn't needed significant modification for 10 years, because it rocks, is stable and just works."
I was a really big Next user, and for me OS X seems to be the natural extension of it. But it was amazing to be using Next machines in the early 90's. They were remarkably ahead of their time.
Most OS X apps...
With leading-edge games like Doom3? You're right.
With device drivers? You're right again.
However, some class of applications can be written once and run anywhere. I've written enterprise apps on Linux that just ran fine the first time they were tried on Windows, Solaris, etc.
Technologies like Java, Python and Ruby make it real. And I'd bet that in the not-too-distant future, games for mobile devices will be "write once run anywhere". J2ME is a good stab at it, but I don't think it's quite there yet.
and the cases burned really well due to the fact that they were cast magnesium
:-)
Poppycock. The cases were a magnesium alloy. The only way the guy got it to burn was to heat it to several thousand degrees so that the alloy broke down. Not to mention that he had to try it with two different cases, AND use tons of lighter fluid to get one to ignite.
Javascript + Nintendo DSi = DSiCade
Imagine the massive development efforts on KDE and Gnome, including the massive rewrites of their codebases, would instead had gone into GNUstep, so that the GNU/Linux and *BSD desktop would be OS X/Cocao source compatibile today [and companies developing for OS X port their software to Linux basically with one more compiler run]...
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
Both good examples, but you missed one. Mac OSX.
Interface builder is not intuitive, it's not even discoverable. Joining objects residing in two separate windows with lines doesn't even make sense from a usability perspective. Even when you eventually figure out how to create classes and join them up to buttons, it is non-obvious how that maps onto actual code. On top of these problems you have to learn a new language just to be able to get your UI to do anything. If the documentation & help system were up to snuff it might shorten the learning curve but they're not - it takes seconds to do a search on MSDN, so why does it takes minutes on OS X?
Thus, the new programmer is faced with an unfamiliar language, an unfamiliar metaphor for UI building, and an unfamiliar framework with bad documentation. I haven't seen such an uncompromising and steep learning curve for a long time. And all that to programme a supposedly user friendly OS.
So yes I do think it is non obvious. In my case it was the first time I actually had to buy a book ("Cocoa Programming for Mac OS X") before I could even figure out what was happening. I haven't seen XCode 2.0 it has to be said, but I sure hope they intend to make it easier to use. Even a few wizards with common design patterns might help somewhat.
why does GNUstep need to have a top devel dir in my home directory ? Why couldn't it be a freaking dot-dir like every other program ?
it seems a bit arrogant to me that something needs its own directory in the root of my home directory.
I don't even use GNUstep, but its always there. It keeps coming back too, after I remove it.
Sunny Dubey
any program worth his shit should have no trouble picking up objective-c (a far simpler and more powerful language than c++). the language barrier really isn't an issue. it's more an issue of mindshare. there are a lot of things that are better in the computing world by design but get largely ignored due to lack of marketing.
- tristan
OpenStep was really popular with several large banks for their internal applications.
Good question, but the fact that you don't see a lot of programs made with a particular framework doesn't mean it's not widely used. 80% of all software (just a guess, maybe it's even more) that is written is custom built software for a specific customer or purpose.
Uh...Doom 3 pretty much was written with that in mind. Once you get their resource/WAD/bytecode/whatever files onto your system, all that matters is the executable and a few library files. I downloaded those from id's site, and had it running on Linux in minutes. Sure, it was primarily designed to work on Windows boxes (or more likely consoles), but with a smart design you can leave your doors open to many markets.
Xcode 2 does fix the documentation/help system. And, yes, Xcode does take a bit of getting used to, but you certainly don't have to buy a *book*. Just reading the online tutorial, which just consists of a few pages of text, was more than enough to get me to understand everything except the language (and you can't possibly call an unfamiliar language a problem with Xcode, any new language is going to be unfamiliar, shock).
Unfortunately, GNUStep is still a bit immature despite being around for many years. The reason there aren't commercial apps isn't because OpenStep isn't great/easy-to-use. It's more likely because the free OpenStep-like environment isn't stable/mature. QT and GTK are stable and mature but you don't see a plethora of non-niche commercial apps for those either.
If it is so easy to port, then why don't I see Photoshop for Red Hat Linux? This is a big market.Photoshop, I believe, is still mostly Carbon, not Cocoa. And, Photoshop on Linux is not a big market. If it were, there would be a QT or GTK Photoshop.
Anything serious use of Objective-C appears to be confined to the Mac platform.OpenStep has been popular in niche areas like banking and scientific apps. Swarm is developed mainly in cross-platform Obj-C. GNU gcc is still relatively behind in Obj-C support but I think Apple is helping to change that.
I don't think the issue here should be Objective-C versus SmallTalk, because they really are two variants of the same flavour of OO language. The shame is that SmallTalk and Obj-C have been marginalized by the C++ approach to OO (with Java being a variant).
I highly encourage anyone who has a chance to try one of these languages out, as this can lead to some new ways of approaching your code.
In particular I am thinking about dynamic binding at runtime. How sweet.
Anyways, cheers to the OpenStep community, and may there always be diversity in programming paradigms.
Well, PostScript has flow control constructs (if/then,loops,etc.), and PDF does not. Personally I think this makes PDF better than PostScript. Want to view page 799 of an 800 page document that's PostScript? Guess what, you have to render the first 798 pages, because there could be state somewhere in there that affects page 799. PDF avoids that.
I have to admit that I did the same when I first launched Interface Builder, but guess what I opened the help and it told of connecting objects to code and I was done, I understood.
You seem to speak ill of IB because its not like everything else you used, you seem unable to realize that this is a GOOD thing, a strength, not a weakness. Interface Builder doesn't generate crappy code for you, instead it generates real objects that are instantiated at runtime then bound to your code. Show me a pre-existing GUI designer that does that and then your point makes sense.
Interface Builder is unilke everything you have ever seen in every way, but every way is better. There is no craapy code generated, there is no retarded boxes nor grids to lay things out with, but instead struts that decide the resizeMask of widgets, and almost all the setting can be made in IB, much more powerful than all teh other GUI editors, and so much easier once you udnerstand.
Unfamiliar framework, yes, bad documentation, no. I mean come on, its new to you so your not familiar with its ins and outs, but just because it doesn't do something like API or library foo doesn't mean it is somehow limited. The docs and the API itself has a clear seperation of tasks and responsibilities, all you need to do is glance through the API docs, or if thats not clear enough for you, start at the Conceptual Docs that explain things without introducing the code involved in detail.
Also as to searching the OS X developer resources, your not doing it right, since the ADC library consolidation makes looking up info generally work the first time and finds exactly what I was looking for when I search not related documents, or documents that will lead me to teh answet, but th answer itself.
The language, lets not cry foul there either, ObjC is blindingly simple to learn if you already know C. It's a few extensions and a CLEAR way of handling objects. The entire reason for teh bracket syntax is to clearly dileaneate object interaction from just memory manipulations of other functions.
You bought a book to introduce you to something new that you didn't know and had to learn, what is surprising about this? Some buy books, some read example code, some just get it. No shame in not understanding, seeking out the knowledge doesn't hurt anyone.
-"I'm one of those Mac people that will break a bottle on the bar and hold it to your throat for bad-mouthing my system"
The NeXTstep and OpenStep APIs are extremely well designed. The are both comprehensive and consistent. Even as new "kits" (now call frameworks) were created, they shared a great deal of consistency with existing frameworks.
The quality of the designs are evident in the very small number of frameworks that needed to be modified in an incompatible way or completely replaced. (The inadequately designed DBKit being replaced by EOF comes to mind.)
When I compare these attributes to Sun's highly inconsistent Java APIs and Microsoft's frequent replacement of frameworks with a completely different "improved yet incompatible" API, I just groan. Even though Sun and NeXT had a relationship, I couldn't figure out why Sun didn't copy some of NeXT's obviously better designs for its own Java frameworks.
I used the high quality, ease of use, and consistency of the NeXTstep/OpenStep APIs as examples that help me significantly improve my own OO design skills.