A favorite link of mine is Tim's w3.org page about the first WWW browser he wrote (actually, it was a browser/editor).
To quote Tim: "I wrote the program using a NeXT computer. This had the advantage that there were some great tools available -it was a great computing environment in general. In fact, I could do in a couple of months what would take more like a year on other platforms, because on the NeXT, a lot of it was done for me already. There was an application builder to make all the menus as quickly as you could dream them up. there were all the software parts to make a wysiwyg (what you see is what you get - in other words direct manipulation of text on screen as on the printed - or browsed page) word processor. I just had to add hypertext, (by subclassing the Text object)"
His observations regarding the productivity of NeXTSTEP development ring true for MacOSX today...
As several people who went to the radical extreme of actually reading the article have pointed out...;-)... it's about developing and using internal game production tools on MacOSX, not about developing games for OSX (though that would certainly be nice too). (Case in point: The context of the article was a production tool I developed while working on a PlayStation game. Console development isn't done using consoles alone!)
The article is not a testimonial about OpenGL performance on the Mac, nor is it a crisicism of OpenGL performance on the Mac.:-) Neither is it an endorsement of Objective-C as the best language in which to write a performance-critical game engine. (For that purpose I would personally choose either a tight subset of C++ or an OO approach to structuring C code.)
The article is about the production process, and developing tools to aid in that process -- a domain in which I can say from experience that developer productivity is far more of a priority than getting every last drop of execution speed -- particularly if you can develop tools that will make a process more efficient for several artists/programmers: the efficiency of the development process then goes up in proportion to the number of people on the team who benefit. That's where Cocoa provides much needed leverage. Objective-C contributes to the efficiency of the development environment by being an appropriately flexible OO language for RAD. IMHO, as the article states & illustrates, it's very appropriate technology for the domain of custom application development.:-)
Of course we should retain a healthy degree of skepticism with respect to the intelligence community, as with any branch of government. But neither let us forget that, as an unfortunate fact of life, we need an intelligence community, imperfect as it may be.
One good lead before 9/11... even an inkling of what might have been planned... and we'd probably have 19 terrorists behind bars right now, instead of thousands dead and billions in damage... *sigh*
A military campaign where we are proud of the fact that we are supported by China, Pakistan, and an alliance of warlords in Afghanistan.
Who says we are "proud of the fact"?
Pakistan is providing a necessary route into Afghanistan, as well as strategic information regarding Taliban positions. The Afghan Northern Alliance is strongly motivated to reclaim territory lost to the Taliban, and our joint effort with them is almost certainly saving the lives of U.S. and allied soldiers who would otherwise be on the ground.
Proud of the fact, no. But unfortunately, there seems to be an extent to which it is to our advantage to ally ourselves with the lesser among our regional adversaries. Yes, this is what got us into trouble before, back when we were backing the Afghans in their fight against the Soviets, and we have clearly got to be more careful this time in how we tie things up. But I don't see much in the way of better alternatives. Just look at the geography of the situation...
I actually hope they don't go too overboard with the new features (in the OS and, implicitly, in new models). The thing I love about my Palm III is that it's simple, and does its job well. (The introduction to O'Reilly's Palm Programming does a good job of illustrating how the Palm's simplicity and appropriate-technology approach has been key to its continued success.)
I looked at WinCE handhelds when I did my shopping (in '98). Their displays, while color, were hard to read (and also cluttered with Windows UI elements that didn't belong -- once you've crammed all the usual window trimmings onto a teensy screen, there's no room left to work on!). In contrast (pun intended), my Palm III's screen, although monochrome, is superbly sharp and clear. It also eats battery power at a fraction the rate of a color screen. To me, this is an appropriate compromise.
Geez, though, I thought. This WinCE machine comes with 8MB of RAM built in. How come the Palm only has 2? A quick trip to the WinCE PDA's system info panel made the reason clear: WinCE itself takes up the first few megs of this formerly vast-seeming space! In constrast, the Palm's use of memory is impressively efficient. Under PalmOS, 2MB goes a long way. I can easily go for a year without bothering to purge old datebook appointments, etc. and not run out of RAM. This despite the many games and other apps that I've downloaded to it, and a few AvantGo channels I keep around. The OS' design makes for very compact apps.
Another bonus: HotSync is a one-button operation, and almost never makes mistakes or requires further intervention on my part. This stands out in my mind as one of the best instances of smart software engineering I've had the pleasure to benefit from...
To conclude this rant: WinCE is an unwieldy hydra of feature-bloat designed to insure that we can experience the joys of Windows everywhere, even on our PDAs... PalmOS is an elegant piece of engineering, appropriate to its task. While it's probably good news that the PalmOS is continuing to be updated, let's not forget a hard-earned bit of folk wisdom: if it ain't broke, don't fix it!
We were set up on Exchange/Outlook at my previous workplace, and the combination seemed to have all kinds of problems. Our Exchange server had a tendency to go down now and then, rendering e-mail inaccessible (and thus briefly increasing productivity, but...). afaik, our IT guy knew what he was doing; Exchange just sucked. This was in a small company too; <20 people/workstations.
Also, from what I remember, Outlook gets testy when it loses its server connection for any length of time, and most of the times I had to reboot my development box (typically 2-4 times a day; thanks Win98!) were due to Outlook hanging and bringing the whole system down with it. (An honorable mention for causing similar problems goes to Visual SourceSafe...) This kind of thing, multiplied by the number of employees you have, is a lame time-suck...
I've never used Delphi myself, so unfortunately I can't speak for the similarities and differences. But perceptually at least it sounds
like we're talking about a power rush experience of somewhat similar magnitude...:^)
For me, the elegance (= power + simplicity) of the Objective-C language weighs heavily in the equation. Objective-C is a much
more dynamic OO language than, say, C++, basically meaning that a lot of symbolic info (method names and type signatures, class
inheritance relationships, etc.) is retained in your compiled code, giving your code the ability to "introspect" usefully about things
at runtime, dynamically load new classes, etc. Of course there is a runtime memory and performance penalty that goes with all
this, but IMHO for the majority of apps development it's well worth it...
Anyhow, to go into detail about all the neat stuff you can do with Obj-C would be a huge tangent here, but suffice it to say for now
that certain properties of Obj-C have enabled Interface Builder to be the incredibly powerful productivity tool that it is. The
biggest difference is that you're basically working with actual object instances that get archived to a persistent store (.nib file).
When your app starts and loads up this.nib file, all of the objects are already wired together and ready to go. i.e. your
"controller" (in the Model-View-Controller sense) object for a particular window or panel (dialog) already has pointers to all of
the panel's UI objects -- buttons, text fields, etc. You do all the "wiring" in Interface Builder, and it gets loaded right up. Menu
items can be easily set to invoke methods of your choosing. The dispatch is clean and direct. There are no ugly switch statements
to write, no casting of message arguments, no constructors that do reams of "pOKButton = new TButton( pDialog,
ID_MY_OK_BUTTON );" just to get pointers to your controls, etc. I don't know how close Delphi comes to this level of
convenience, but the whole setup is very, very elegant. It's amazing how much tedious hand-coding it eliminates. Basically your UI code boils down to just what is needed to get things to behave the way you want them to.
Mac OS X being essentially the latest incarnation of OpenStep (with MacOS emulation being the single most significant addition, IMHO), it's got far and away the most productive environment (tools + object libraries) for GUI app development I've ever had the privilege of working with... It's amazing how little coding it takes to put a good app together once you've wired up the UI in InterfaceBuilder... (Back when I was working at a game company, I used OpenStep Enterprise 4.2 on NT to put together a very helpful in-house GUI tool for PSX texture VRAM layout that I'd just never have had the time to build with any other tool set.) OpenStep (now "Cocoa" [cringe]) truly enables one (or a few) developer(s) to to the work of many.
I'm burning my own savings right now working solo on an open source project, and have been doing the prototyping on Mac OS X Server because the productivity benefits are just so great. (I've also just joined ADC, taking advantage of the $400 special, and am eagerly awaiting DP4 and the Beta...) I can't imagine being able to accomplish what I'm working on in a reasonable amount of time any other way...
For more development info, I heartily suggest you check StepWise -- in particular their nice archive of back articles, including numerous pieces on development topics.
Also, be sure to check out the Mac OS X mailing-lists (archives available) maintained by Omni Development (a longtime OpenStep consulting & development house -- try OmniWeb, it's great!). In particular: macosx-dev is where development stuff gets discussed.
I use both Linux and Mac systems, and hope to see both platforms continue to maintain healthy followings (healthy enough to insure significant continued software development & hardware support). Whether either of these OSes ever topples Windows [the embodiment of all we love to hate] is immaterial to me. I would much rather see neither reach this goal of questionable value, if the cost had to be losing one in the process. As much frustration as OS incompatibilities cause, I think realistically the world needs a healthy diversity of OS (or at least UI layer) alternatives.
These days I am doing most of my work on Mac OS X Server (eagerly awaiting the public beta of Mac OS X!). The one overwhelming reason for this: OpenStep (subsequently dubbed "YellowBox" and now "Cocoa" [*cringe*] by Apple) is hands-down the most productive and intelligently engineered OO application development platform that I have yet had the privilege of working with. I have a great deal of admiration for the work that was done by NeXT's software engineers, based on the foresight and clear thinking that is evident in the OpenStep frameworks and tools (most notably InterfaceBuilder). And, I love working in Objective-C.
If the Mac was to vanish, my greatest worry would be that it might take OpenStep/Cocoa into the dark night with it. For years, this magnificent development framework remained the exclusive domain of Fortune 500 custom apps development (discounting NeXT's initial inept foray into upper academia), because that was the narrow target market NeXT chose after it abandoned the hardware end of its business. By far the most exciting thing about Mac OS X to me (since I can already get the UNIX part by just running Linux), is that it will make the power of OpenStep available to mainstream developers for the first time.
If the Mac vanished off the map tomorrow, GNUstep would be the one remaining hope for OpenStep. However, a great deal of work remains to be done to complete GNUstep, and I think this endeavor stands to benefit from Mac OS X's success. (As more developers discover what they can do with Cocoa, I expect there will be increasing demand for the ability to run Cocoa apps on other platforms. Also, Apple's continued development of Mac OS X and Cocoa, particularly in the realm of user-interaction improvements, could help provide impetus and direction for continuing to evolve GNUstep beyond the base OpenStep vision.)
In this sense, I think it would be a real loss to the development community (and thus to the end user) if Mr. Raymond turned out to be right about the Mac's eventual demise.
Slashdot Mirror
To quote Tim: "I wrote the program using a NeXT computer. This had the advantage that there were some great tools available -it was a great computing environment in general. In fact, I could do in a couple of months what would take more like a year on other platforms, because on the NeXT, a lot of it was done for me already. There was an application builder to make all the menus as quickly as you could dream them up. there were all the software parts to make a wysiwyg (what you see is what you get - in other words direct manipulation of text on screen as on the printed - or browsed page) word processor. I just had to add hypertext, (by subclassing the Text object)"
His observations regarding the productivity of NeXTSTEP development ring true for MacOSX today...
CousinChimpy
(Troy Stephens)
The article is not a testimonial about OpenGL performance on the Mac, nor is it a crisicism of OpenGL performance on the Mac. :-) Neither is it an endorsement of Objective-C as the best language in which to write a performance-critical game engine. (For that purpose I would personally choose either a tight subset of C++ or an OO approach to structuring C code.)
The article is about the production process, and developing tools to aid in that process -- a domain in which I can say from experience that developer productivity is far more of a priority than getting every last drop of execution speed -- particularly if you can develop tools that will make a process more efficient for several artists/programmers: the efficiency of the development process then goes up in proportion to the number of people on the team who benefit. That's where Cocoa provides much needed leverage. Objective-C contributes to the efficiency of the development environment by being an appropriately flexible OO language for RAD. IMHO, as the article states & illustrates, it's very appropriate technology for the domain of custom application development. :-)
CousinChimpy
(Troy Stephens)
Actually, I am a programmer. And I wrote the article without consulting with Apple. :-)
But maybe I misssed my true calling...
-TS
If you believe that, you probably also believe that Israel, the Mossad, and the Easter Bunny were involved.
Perhaps someone's watched a few too many X-Files episodes?
One good lead before 9/11 ... even an inkling of what might have been planned ... and we'd probably have 19 terrorists behind bars right now, instead of thousands dead and billions in damage... *sigh*
Who says we are "proud of the fact"?
Pakistan is providing a necessary route into Afghanistan, as well as strategic information regarding Taliban positions. The Afghan Northern Alliance is strongly motivated to reclaim territory lost to the Taliban, and our joint effort with them is almost certainly saving the lives of U.S. and allied soldiers who would otherwise be on the ground.
Proud of the fact, no. But unfortunately, there seems to be an extent to which it is to our advantage to ally ourselves with the lesser among our regional adversaries. Yes, this is what got us into trouble before, back when we were backing the Afghans in their fight against the Soviets, and we have clearly got to be more careful this time in how we tie things up. But I don't see much in the way of better alternatives. Just look at the geography of the situation...
I looked at WinCE handhelds when I did my shopping (in '98). Their displays, while color, were hard to read (and also cluttered with Windows UI elements that didn't belong -- once you've crammed all the usual window trimmings onto a teensy screen, there's no room left to work on!). In contrast (pun intended), my Palm III's screen, although monochrome, is superbly sharp and clear. It also eats battery power at a fraction the rate of a color screen. To me, this is an appropriate compromise.
Geez, though, I thought. This WinCE machine comes with 8MB of RAM built in. How come the Palm only has 2? A quick trip to the WinCE PDA's system info panel made the reason clear: WinCE itself takes up the first few megs of this formerly vast-seeming space! In constrast, the Palm's use of memory is impressively efficient. Under PalmOS, 2MB goes a long way. I can easily go for a year without bothering to purge old datebook appointments, etc. and not run out of RAM. This despite the many games and other apps that I've downloaded to it, and a few AvantGo channels I keep around. The OS' design makes for very compact apps.
Another bonus: HotSync is a one-button operation, and almost never makes mistakes or requires further intervention on my part. This stands out in my mind as one of the best instances of smart software engineering I've had the pleasure to benefit from...
To conclude this rant: WinCE is an unwieldy hydra of feature-bloat designed to insure that we can experience the joys of Windows everywhere, even on our PDAs... PalmOS is an elegant piece of engineering, appropriate to its task. While it's probably good news that the PalmOS is continuing to be updated, let's not forget a hard-earned bit of folk wisdom: if it ain't broke, don't fix it!
Also, from what I remember, Outlook gets testy when it loses its server connection for any length of time, and most of the times I had to reboot my development box (typically 2-4 times a day; thanks Win98!) were due to Outlook hanging and bringing the whole system down with it. (An honorable mention for causing similar problems goes to Visual SourceSafe...) This kind of thing, multiplied by the number of employees you have, is a lame time-suck...
Be sure to look before you leap...
I've never used Delphi myself, so unfortunately I can't speak for the similarities and differences. But perceptually at least it sounds like we're talking about a power rush experience of somewhat similar magnitude... :^)
For me, the elegance (= power + simplicity) of the Objective-C language weighs heavily in the equation. Objective-C is a much more dynamic OO language than, say, C++, basically meaning that a lot of symbolic info (method names and type signatures, class inheritance relationships, etc.) is retained in your compiled code, giving your code the ability to "introspect" usefully about things at runtime, dynamically load new classes, etc. Of course there is a runtime memory and performance penalty that goes with all this, but IMHO for the majority of apps development it's well worth it...
Anyhow, to go into detail about all the neat stuff you can do with Obj-C would be a huge tangent here, but suffice it to say for now that certain properties of Obj-C have enabled Interface Builder to be the incredibly powerful productivity tool that it is. The biggest difference is that you're basically working with actual object instances that get archived to a persistent store (.nib file). When your app starts and loads up this .nib file, all of the objects are already wired together and ready to go. i.e. your
"controller" (in the Model-View-Controller sense) object for a particular window or panel (dialog) already has pointers to all of
the panel's UI objects -- buttons, text fields, etc. You do all the "wiring" in Interface Builder, and it gets loaded right up. Menu
items can be easily set to invoke methods of your choosing. The dispatch is clean and direct. There are no ugly switch statements
to write, no casting of message arguments, no constructors that do reams of "pOKButton = new TButton( pDialog,
ID_MY_OK_BUTTON );" just to get pointers to your controls, etc. I don't know how close Delphi comes to this level of
convenience, but the whole setup is very, very elegant. It's amazing how much tedious hand-coding it eliminates. Basically your UI code boils down to just what is needed to get things to behave the way you want them to.
Hope to see you on macosx-dev! :-)
-Troy
Mac OS X being essentially the latest incarnation of OpenStep (with MacOS emulation being the single most significant addition, IMHO), it's got far and away the most productive environment (tools + object libraries) for GUI app development I've ever had the privilege of working with... It's amazing how little coding it takes to put a good app together once you've wired up the UI in InterfaceBuilder... (Back when I was working at a game company, I used OpenStep Enterprise 4.2 on NT to put together a very helpful in-house GUI tool for PSX texture VRAM layout that I'd just never have had the time to build with any other tool set.) OpenStep (now "Cocoa" [cringe]) truly enables one (or a few) developer(s) to to the work of many.
I'm burning my own savings right now working solo on an open source project, and have been doing the prototyping on Mac OS X Server because the productivity benefits are just so great. (I've also just joined ADC, taking advantage of the $400 special, and am eagerly awaiting DP4 and the Beta...) I can't imagine being able to accomplish what I'm working on in a reasonable amount of time any other way...
For more development info, I heartily suggest you check StepWise -- in particular their nice archive of back articles, including numerous pieces on development topics.
Also, be sure to check out the Mac OS X mailing-lists (archives available) maintained by Omni Development (a longtime OpenStep consulting & development house -- try OmniWeb, it's great!). In particular: macosx-dev is where development stuff gets discussed.
For general OpenStep info, you might want to look on the GNUstep site (bearing in mind that Cocoa is a growing superset of OpenStep).
Hope this helps!
These days I am doing most of my work on Mac OS X Server (eagerly awaiting the public beta of Mac OS X!). The one overwhelming reason for this: OpenStep (subsequently dubbed "YellowBox" and now "Cocoa" [*cringe*] by Apple) is hands-down the most productive and intelligently engineered OO application development platform that I have yet had the privilege of working with. I have a great deal of admiration for the work that was done by NeXT's software engineers, based on the foresight and clear thinking that is evident in the OpenStep frameworks and tools (most notably InterfaceBuilder). And, I love working in Objective-C.
If the Mac was to vanish, my greatest worry would be that it might take OpenStep/Cocoa into the dark night with it. For years, this magnificent development framework remained the exclusive domain of Fortune 500 custom apps development (discounting NeXT's initial inept foray into upper academia), because that was the narrow target market NeXT chose after it abandoned the hardware end of its business. By far the most exciting thing about Mac OS X to me (since I can already get the UNIX part by just running Linux), is that it will make the power of OpenStep available to mainstream developers for the first time.
If the Mac vanished off the map tomorrow, GNUstep would be the one remaining hope for OpenStep. However, a great deal of work remains to be done to complete GNUstep, and I think this endeavor stands to benefit from Mac OS X's success. (As more developers discover what they can do with Cocoa, I expect there will be increasing demand for the ability to run Cocoa apps on other platforms. Also, Apple's continued development of Mac OS X and Cocoa, particularly in the realm of user-interaction improvements, could help provide impetus and direction for continuing to evolve GNUstep beyond the base OpenStep vision.)
In this sense, I think it would be a real loss to the development community (and thus to the end user) if Mr. Raymond turned out to be right about the Mac's eventual demise.