Re: Cocoa/Windows parallel dvlpmt
Re: Cocoa/Windows parallel dvlpmt
- Subject: Re: Cocoa/Windows parallel dvlpmt
- From: Karl Kraft <email@hidden>
- Date: Wed, 4 Feb 2004 12:37:09 -0600
This is starting to brew into a flame fest, so I'm going to keep it
down to this one post. Which I suppose is another way of saying I
wonder whether I should even send this one. But in the interest of
injecting some real world experience about GNUstep, cocoa on windows,
etc, here goes.
I do contracting work for a medium size company that started
development with NeXTSTEP/FIP. The project was a large mission-critical
data visualization application. It was a nice quick way to get the
project done, and the project did go live on NeXSTEP/FIP.
As you all know, NeXTSTEP was superseded by OPENSTEP. The boxes were
upgraded to OPENSTEP for use and development, although the source
continued to stay with the NeXTSTEP API/ABI, which allowed it to run on
OPENSTEP.
Along the way we looked at porting the source to YellowBox/WIndows,
which was the OpenStep API for the Windows platform. Most of the
underlying core classes and business logic was ported, but the project
was never completed. It was eventually decided to go with a
Windows/Visual Basic solution which was started then.
However, we took that reusable business logic and created a new
project, which was a voice response unit. (people call a phone number,
and using touch tones, can perform DB inquiries) Again this is real
mission-critical software.
The VRU was developed using OPENSTEP/FIP. The problem is that as a
VRU, it needs 16+ phone lines (serial ports) to answer. And the idea
of writing the drivers for OpenStep didn't seem thrilling. So we made
it run on GNUstep. Since the app isn't graphical in nature, and since
I had poured time and money into GNUstep on other projects and solved
any bugs that affected me, the port was relatively painless.
It was made more painless by the use of nfmake (which I wrote) which
was a build system that could build using PB.project files. This
allowed us to develop on OPENSTEP/FIP and YellowBox which were much
more mature and usable than GNUstep at that point.
If I had to do a project on GNUstep today, I would be pretty
comfortable using the foundation classes. They are probably near 100%
complete.
That VRU system continues to run today, on GNUstep, with about 40 phone
lines under control.
I eventually ported nfmake for building applications for the palm
handheld. My last significant GNUstep development was mid 2001.
When NeXT was acquired by Apple, and the plans for Rhapsody were laid
out, and the Windows/Visual Basic plan hadn't delivered fruit, the
decision was made to reactivate the port, using OPENSTEP as a platform.
The plan was to get it up and running, get users using the ported copy
on their exiting OPENSTEP boxes, and then decide whether Apple was
serious about OpenStep on Macs or finish the project on GNUstep.
Now, as you can see the company in question was already using linux,
already using GNUstep, certainly wasn't afraid of exotic software (they
ran OPENSTEP/FIP), and wasn't lakcing for hardware and resources that
would work with GNUstep. So the decision was very pragmatic and
non-emotional.
About a year ago, the decision was made to go OSX instead of GNUstep.
Porting from OpenStep to OSX was painless. It was an under a day
affair.
Even though it meant buying all new hardware, the cost of completing
the project on OSX, and the chance that it would complete on OSX was
higher than GNUstep. It was also easier to find OSX developers than
GNUstep developers. OSX was easier to setup, maintain, train users on,
and had productivity apps that the users wanted and were comfortable
with.
And having to "pick a horse" we were confident that Apple would advance
OSX quicker during the coming years than GNUstep would.
In the end we made the right choice, and the app has been live for
several months now. Apple has advanced not only the OS itself, but the
development tools significantly over the last year. The users love the
machines, they interoperate easily with everything we need, and the
work is getting done.
Currently we are talking about folding back the changes we made to the
business logic and core libraries back into the VRU system. We are
also considering peeling off part of the app that does automated
publishing of PDFs to the web and putting that into a GNUstep project,
so I'll probably be writing a version of xcodebuild that works on
GNUstep.
Looking back, I realize my opinion of GNUstep, based on real world
usage and experience, has been the same for the last 5 years:
* wouldn't hesitate to use it for a command-line or server-type tool
* foundation is as bug free as OpenStep ever was or OSX is
* not ready for the desktop except for simple to medium applications
* better to write on the gold standard (OSX) and then port to GNUstep
* GNUstep makes a great escape hatch in case something goes wrong with
OSX. In that regards, the existence of GNUstep makes OSX a more
compelling platform to write for.
--
K2 // Karl Kraft // email@hidden
To purchase it is not like spending money, but rather it is an
investment in the future, in a blow against the empire
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.