Eliot Muir responded to my ravings as follows:
> I think Logical Methods is in a similar conundrum
> with Profit. I'm sure there are loads of companies
> with worse legacy problems.
>
> Don't take offense by my comments - I'm
> sure you're aware of your risks and have picked
> the best path for your company.
I'm not taking offense, I just fighting against the assumption that everyone
should be writing thin-client, RPC, C++ apps. I'll present some arguments
below.
> I think COM will go ... eventually ...
> although having said that - it's a pretty
> simple protocol - it's not too bad - it has
> been ported to Linux.
The fact that you can now get COM on Linux is not going to convince me its a
good standard. We already had the full DCE RPC standard that worked cross
platform and CORBA that provided a much nicer environment at greater speed.
That Microsoft weighted in with COM as an 'inductry standard' does not make
it a holy thing.
> I think C++ is here to stay for a long time
> it's an open ANSI standard, there are many compilers
> available for it - practically all the really big
> commercial applications are written in it.
So was FORTRAN and COBOL and they are now religated to small corners of the
industry. I've been tracking C++ every since it poked its head up as cfront,
and while I can agree with some of the design I have very serious
reservations about much of the language. In any case a 'long time' in this
industry is about 10 years, try and remeber what you were writing on and
with 10 years ago 8-)
> I don't know that the VCL will be so long lived.
We don't care that it won't be long lived, or that its from a single vendor,
or that its not an open standard. We care that its the single best RAD
product available today on the market and that we can produce great
software, In 10 years we'll probably be doing another rewrite to a new
platform, with a new language, and using a new library and the existing
tools will certainly survive that long in our market segment.
> But the nature of accounting surely didn't change
> between DOS and Windows? It should have been possible
> keep the two layers separate.
The nature of accounting didn't change, but many things that contribute to
the presentation of accounting information have certainly changed. Also the
tools and machines certainly changed making things possible today that were
never possible back when Prophet and Profax were written.
Concider that when Prophet was written we were targetting machines 20MHz 286
boxes with 1Meg of RAM plus some EMS or XMS if we were lucky. We're talking
the glory days of 1984 here. MSDOS has just made it to version 3, and the
tools available for the platform were not that good. LML required a tool
that could support a large application with upto 2MB of executable code. In
those dfays that ment that we had to use overlay technology to quish all
that code into the available RAM.
Profax's DOS product was developed about the time that DOS tools started to
mature and the market was starting to debate the merits of building code for
Windows 3.0.
In environments like above become very difficult to worry about things like
UI/data seperation when you have much more serious problems in geting your
code to fit into the small amout of memory available at all!
Now onto the issue of things like using thin-client, COM and such:
Again our decision not to use such things spring directly from the market we
are addressing. We produce accounting software that spans from a single
machine small company, up to midsized LAN's running medium sized companies.
In most cases the suctomers doesn't care about technology, has no support
people in-house, doesn't want to pay much for outside support, and just
wants a product that goes with no problems.
As such there is a serious problem in using technologies such as COM, DCOM,
and even TCP/IP! Because they are harder to configure and keep running than
the out-of-box peer-to-peer networking you have a much higher cost of
ownership, installation and maintaince than a product that avoids anything
more than file sharing. A simpler product also means that you can develop,
debug and test it more simply than one with more complex features.
So our current development strategy rests on targeting a known market
demanding simple, reliable accounting software that they can run for another
15 years with minimal cost of ownership.
So there you have it, market segment dictates technology utilisation.
Cheers, Max.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
