I thought long and hard before moving to Delphi - I thought about using
Power Builder because of the ability to program for more than one platform
(BORLAND - are you hearing this); however, my current project is a client
server project working with Windows 95/NT. Facing the facts - Delphi once
you learn it (which I'm still learning) is really powerful and designed
for the beginner and the expert. Power Builder also has a steep learning
curve and isn't as flexible as Delphi. At least that is what a guy in my
office who worked with Power Builder for over a year has said.
Back to your original question - I'm starting to see more and more
companies asking for Delphi exerience. Therefore, I think you will do
well by learning Delphi.
Best of Luck,
Michael
I am a VB3/VB4 developer who recently started coding in Delphi.
IMHO Delphi does have distinct advantages. Being a 'real' (ie,
compiled) language, it is much faster than p-code (Borland claims
15-50x, and I have gotten similar response in number cruching apps). It
supports and encourages good programming style. Also, I have had no
problems moving .EXEs between machines; in VB, it is a challenge to
ensure all DLLs, etc are the proper version, and in some cases a
program compiled on machine A just will not run on machine B (although
it will if I compile the same source on machine C).
Delphi is not, however as easy to use as VB. I have found the BDE
cumbersome, so much so that I am evaluating ODBCExpress (at first look,
it is a VERY good product) so that I can get back to the ODBC, which is
the standard way of database access.
The biggest complaint I have is that the help system is simply awful. I
got used to the help files in VB which actually gives sample routines
showing the use of a method or property. With Delphi, you're on your
own. Help topics are often missing, or mis-indexed (ie, point you to a
completly different topic); when it exists the explanation and sample
code are laughably sparse, a Control with a method Foo might have
example code such as:
Control.Foo;
and nothing else - this is not very helpful.
Also, Delphi seems to assume that everyone wants to access data through
bound controls. Often, one wants to process the data as it is being
read - this can be done nicely within a record using calculated fields,
but to summarize data (subtotals, etc), it is much cleaner to read in
the data yourself, add the summary stats, and write it to a grid (as
long as your datasets are not horendously large). Additionally, in my
experience, using bound controls in a multi-user app can be a Very Bad
Idea, because one is never quite sure when the bound controls are
locking or updating records; I much prefer to read the data and process
data updates myself. Thus, I have had to 'work around' Delphi to do
data access.
Although I have my complaints, Delphi is overall a very good language,
and in many aspects is the 'best of breed' RAD tool. Delphi does give
me a stable, powerful platform on which to work, although the learning
curve was very frustrating, do mainly to documentation shortfalls.
I am sure I have stirred up a hornet's nest of constasting opinions on
these points. Fire away.
Regards,
Thomas Pugh
>Control.Foo;
Actually no, I think I agree with you on every point. Certainly it behooves
Borland to observe how posts like this one imply that on many fronts the
company's [documentation] is its own worst enemy, and how documentation
quality is one thing that Microsoft categorically does -extremely- well. They
have successfully turned that to their competitive advantage and I would
heartily wish that Borland would simply follow suit.
The bit about bound-controls-or-not does not quite match my experience,
although the target of my apps is normally BDE itself and not ODBC where the
rules are more SQL-compliant and therefore different. But certainly the last
paragraph sums it up well. "The learning curve was frustrating .. mainly due
to documentation shortfalls!"
Sometimes I think that Borland would score a major "technical" coup by
skipping the next technical geegaw and putting solid resources behind making
the documentation better. And I'm not slamming the documentation folks when I
say these things... I'm challenging the management to give those teams more
resources, more attention, more recognition that what *they* do is just as
important to the bottom-line as whatever Anders ever did.
/mr/
[ much text deleted....I agree with it to a large extent...but]
>
>Sometimes I think that Borland would score a major "technical" coup by
>skipping the next technical geegaw and putting solid resources behind making
>the documentation better. And I'm not slamming the documentation folks when I
>say these things... I'm challenging the management to give those teams more
>resources, more attention, more recognition that what *they* do is just as
>important to the bottom-line as whatever Anders ever did.
In the main I agree here, but to play devil's advocate, I tend to find it hard
to believe that ANY documentation team is going to satisfy ALL users. There is
certainly much room for improvement, but I feel there will always be those who
want to do 'X', but the documentation team never considered 'X', or approached
'X' thru 'Y', or there was no one with the experience in 'X' to provide adequate
direction.
>
>/mr/
Delphi (for all the worts that the doco DESERVES) is, to my mind, an
excelent product that allows the developer to handle almost any challenge.
Sure the BDE (for version 1 - haven't needed to try V2 yet) has it's probs
with things like unflushed buffers and Report Smith is a real dog (yeah
Crystal) but overall - to me it's a winner.
Cheers....
:-}
Charles I. Payne <CPa...@Infoave.net> wrote in article
<01bbfd4b$cab2a360$914374cc@bad-karma>...
> In the main I agree here, but to play devil's advocate, I tend to find it hard
> to believe that ANY documentation team is going to satisfy ALL users. There is
> certainly much room for improvement, but I feel there will always be those who
> want to do 'X', but the documentation team never considered 'X', or approached
> 'X' thru 'Y', or there was no one with the experience in 'X' to provide adequate
> direction.
Again, I agree with this for the most part. I do, however, feel very strongly that
Borland should have mentioned, somewhere, everything that they included. Recently
I wrote a component to work with the registry using API call, only to find that
such a component exists but was not documented ANYWHERE. There are many such cases,
least of all being the RTI library.
Pe
Regards
Jeffrey R. Shapiro
the compiler
Thomas Pugh <tp...@nforce.com> wrote in article
<32D740...@nforce.com>...
> Charles I. Payne wrote:
> >
> > I'm a consultant wanting to do contract programming work. I'm wondering
> > what languages should I add to my resume. I do VB4 and I'm learning
java.
> > I've ordered DELPHI 2.0 Developer version. I know I'm in group that
will be
> > biased, but is there alot
> > of work out there.
> > Thanks
> > Charles Payne
>
> I am a VB3/VB4 developer who recently started coding in Delphi.
>
> IMHO Delphi does have distinct advantages. Being a 'real' (ie,
> compiled) language, it is much faster than p-code (Borland claims
> 15-50x, and I have gotten similar response in number cruching apps).
............
>
> Regards,
> Thomas Pugh
>