Eliot Muir sayeth:
> The difference from Profax's approach and Credit Suisse is that Borland or
> Microsoft could go belly up tommorrow and all Credit Suisse needs to do is
> switch client technologies if it wants to continue development -
> Profax and any
> company which completely bets on one company's technology for their
> infra-structure is going to be in a sticky position if that
> company goes under.
The difference here is one of scale.
Credit Suisse sounds distinctly like a large corporate entity where the
guiding factors are being able to replace programmers from the market,
having a large pool of contractors available for big jobs, and having
projects maintainable across programmer generations. In this environment
(and I've worked there) individual execellence is abhored, and all work is
forced into market driven commanality (C/C++, VB, Oracle, RPG3, COBOL etc).
Profax has three programmers, targets one platform (DOS/Windows) and so has
the liberty to choose any development environment it feels confortable with.
The current DOS product was developed in Top Speed C++, a company that has
since gond belly up, but provided DOS based DLL's, 32bit DOS extenders and
other stuff way before anyone else provided these. In our move into the
Windows market we choose Delphi as the best of breed environment that would
allow us to build the same quality of software as our DOS products.
Just because Top Speed has vanished into history doesn't mean that their
compilers have stopped working, and we are still actively writing code using
the old tools. If Borland were to completly vanish overnight we would still
have Delphi 4 and all our working code to work with for the next few years.
If Microsoft were to completly vanish overnight we would still have millions
of Windows machines in the world and a market for products written to the
Win32 API.
> It rather like say making the transition from a DOS accounting
> system written
> in non-portable Modula 2 to Windows when not quite enough initial
> effort was
> made to separate out the layers - there quite are a few companies in that
> unhappy position of having a good DOS product which is impossible
> to port to Windows.
As I have help to write one DOS accounting system in written in non-portable
Modula-2, and I suspect that there are no other Modula-2 accounting products
in New Zealand, I know exactly what went on in the internals of that system
8-)
DOS products were written in their day in the compilers available and the to
interfaces possible on the machines that were common. I'm of the opinion
that porting DOS software to Windows is a bogus exercise due to the very
different nature of Windows. I've benn involved in porting 16 bit C code
into the Mac and Windows and its a bogus execerise as well, as writing
portable C is such a damn diffucult thing.
> (BTW - I do practice what I preach - I think Delphi is great - but HL7
> Chameleon only uses it for a thin front end - all the real work
> is done in C++
> with a COM wrapper - both the GUI front end and the COM wrapper can be
> completely replaced without touching the rest of the product.)
In 10 or 15 years, when C++ is an outdated language, and COM is an obscure
historical interface, you will have just as much trouble porting to the new
machines as the DOS to Windows transition. Your application is portable
today, because it relies on todays technologies, but historically speaking
tomorrows technologies don't provide much mercy on todays stuff.
Cheers, Max.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
