Delphi Vs. PowerBuilder
JRARTH
reliable and has a better development environment. The real problem is
that PB is not extensible; if you want to enhance the controls provided --
you'd better be a great at C/C++. When using Delphi, I only need one tool
to get the job done.
As for PB 5.0, converting an interpreted language into C++ is a very
imposing task! Even if they can get it right every time, I doubt that the
code will be very efficient. I saw a demo of 5.0 recently, it GPF'd! The
result was faster than 4.0, but still alot slower than Delphi. I've been
waiting since 3.0 for stability, I'm tired of waiting.
I dumped VB for PB, then PB for Delphi. I refuse to hooked on a tool set!
If something shows up that smokes Delphi, I'll dump Delphi. Until then,
Delphi is my #1 choice.
Mike Swaim
>As for PB 5.0, converting an interpreted language into C++ is a very
>imposing task!
Not nearly as imposing as converting C++ to machine language.
Besides, PB 5 spits out C, not C++.
Mike "Agent of Chaos" Swaim|sw...@phoenix.net|Disclamer: I Lie
Craig Wagner
>It really isn't fair to compare PB with Delphi. Delphi is faster, more
>reliable and has a better development environment.
Faster, right now. More reliable, maybe. Better development environment? That's
a matter of taste. Personally, I don't care for it.
>The real problem is that PB is not extensible; if you want to enhance the
>controls provided -- you'd better be a great at C/C++.
Or learn how to use user objects properly. I've seen this comment from too many
people to buy into it. When I spend 20 minutes explaining how to use user
objects they go "Oh, I didn't realize it was that easy." Just lack of education
to begin with 80% of the time.
>As for PB 5.0, converting an interpreted language into C++ is a very
>imposing task! Even if they can get it right every time, I doubt that the
>code will be very efficient. I saw a demo of 5.0 recently, it GPF'd!
It's BETA SOFTWARE for cryin' out loud!
And it's converting it to C, not C++, for portability to the other platforms on
which PowerBuilder runs (say, when is Delphi going to have their Motif and Mac
versions ready?).
Before shooting something down, at least try and get your facts straight.
>result was faster than 4.0, but still alot slower than Delphi.
Bullshit, plain and simple. I've done tests myself between the two and to use
the loaded phrase "a lot slower" is BS. Delphi benchmarks can be cooked due to
some tricky things the compiler does.
>I dumped VB for PB, then PB for Delphi. I refuse to hooked on a tool set!
>If something shows up that smokes Delphi, I'll dump Delphi. Until then,
>Delphi is my #1 choice.
Now all you have to do is find a significant number of companies adopting it and
you're all set.
---
Craig Wagner | E-mail: wag...@spots.ab.ca
Calgary, AB | Fidonet: 1:134/66
(403) 271-7387 | Excrement occurs!
Dennis Courtney
> the loaded phrase "a lot slower" is BS. Delphi benchmarks can be cooked due to
> some tricky things the compiler does.
as fast as Delphi? I use PB, VB, C++ and Delphi
and I too have "done some tests" and I gotta tell
you Delphi is faster (and that ain't BS).
Both InfoWorld and PCWeek have had articles in the
last week benchmarking the speed of Delphi. Each
noted that Delphi was FASTER than both MicroSoft
Visual C++ and Borland C++ (but slower than
Watcom). Now, I ask you, do you really think that
both of the technical staffs of these publications
were taken in by "tricky things the compiler does"
as you put it? BTW, that "tricky thing the
compiler does" is called machine code.
It all gets down to who we should believe - the
technical staff of major publications we've come
to rely on over the years or some guy in Alberta?
>
> Now all you have to do is find a significant number of companies adopting it and
> you're all set.
> Craig Wagner | E-mail: wag...@spots.ab.ca
> Calgary, AB | Fidonet: 1:134/66
> (403) 271-7387 | Excrement occurs!
Craig,
I'm not suggesting that PB is a bad product, in
fact there are some things I like about it. For
instance, I do like the hooks in PB for group
programming and I believe it to be ahead of Delphi
in that area. I just don't think we need to get
religious about it.
Bill Touchstone
In article 1105...@198.53.64.1, wag...@spots.ab.ca (Craig Wagner) writes:
>the loaded phrase "a lot slower" is BS. Delphi benchmarks can be cooked due to
>some tricky things the compiler does.
Hmmmm. You seem to be saying they make their compiler do tricks and the
resultant code is faster?
I think that is called optimization and believe it or not, a lot of compilers
can do it now. Neat times we are in :)
As far as whether you call it tricky or optimization, Delphi does it and PB
doesn't. As for me, I'll go with whatever it takes to produce fast code.
>
>>I dumped VB for PB, then PB for Delphi. I refuse to hooked on a tool set!
>>If something shows up that smokes Delphi, I'll dump Delphi. Until then,
>>Delphi is my #1 choice.
And the choice of a rapidly growing section of the market. Only dinosaurs
excluded.
>
>Now all you have to do is find a significant number of companies adopting it and
>you're all set.
As managers find out about it, they switch. But even there you have dinosaurs.
>---
>Craig Wagner | E-mail: wag...@spots.ab.ca
>Calgary, AB | Fidonet: 1:134/66
>(403) 271-7387 | Excrement occurs!
Bill Touchstone
ycc...@gate.net
Alex Nolasco
IMHO, it's up to the programmer to do the thing right.. Would it help if
I use o(n^2) algorithms? or O(nlogn)?? in either language, the programmer
would make a difference..
Craig Wagner
>> Bullshit, plain and simple. I've done tests myself between the two and to use
>> the loaded phrase "a lot slower" is BS. Delphi benchmarks can be cooked due to
>> some tricky things the compiler does.
> Is it your position that the PowerBuilder code is
>as fast as Delphi? I use PB, VB, C++ and Delphi
>and I too have "done some tests" and I gotta tell
>you Delphi is faster (and that ain't BS).
But let's consider how that impacts the real world. In a loop which I executed
10,000,000 times, PowerBuilder 5.0 beta (build 107) took 45 seconds and Delphi
1.0 took 30 seconds. Even if we completely ignore the following two facts...
1. In a new release performance tuning is usually the last thing done (i.e.
PowerBuilder 5.0 beta is probably not as fast as it's going to get).
2. The PowerBuilder 5.0 application was 32-bit, meaning its execution was
pre-emptively multi-tasked in my Win95 environment and Delphi was 16-bit so it
took over the machine.
That still means that in a single execution of this loop Delphi will run
0000015 seconds faster. Guess you're right, Delphi is faster. Then again, if it
requires 1,000,000 iterations of a loop to generate a 1.5 second difference,
does it really matter? Given the narrow margin of victory, I think I'll take the
ease of PowerScript over Pascal.
>as you put it? BTW, that "tricky thing the
>compiler does" is called machine code.
Actually, it plays little games that make benchmarketing easy. For example, if
you increment a variable in a loop, but subsequent to the loop you don't use it,
the compiler simply skips the loop. Makes the benchmarketing numbers look really
good, but it's not going to do much for you in the real world.
>It all gets down to who we should believe - the
>technical staff of major publications we've come
>to rely on over the years or some guy in Alberta?
Very mature, slamming someone because of where they live. And if you've been
around at all you should know by now that you can't believe everything you read.
Kyle A. Miller
>Dennis Courtney <DEN...@IADB.ORG> wrote:
>>> Bullshit, plain and simple. I've done tests myself between the two and to use
>>> the loaded phrase "a lot slower" is BS. Delphi benchmarks can be cooked due to
>>> some tricky things the compiler does.
>> Is it your position that the PowerBuilder code is
>>as fast as Delphi? I use PB, VB, C++ and Delphi
>>and I too have "done some tests" and I gotta tell
>>you Delphi is faster (and that ain't BS).
>But let's consider how that impacts the real world. In a loop which I executed
>10,000,000 times, PowerBuilder 5.0 beta (build 107) took 45 seconds and Delphi
>1.0 took 30 seconds. Even if we completely ignore the following two facts...
>1. In a new release performance tuning is usually the last thing done (i.e.
>PowerBuilder 5.0 beta is probably not as fast as it's going to get).
>2. The PowerBuilder 5.0 application was 32-bit, meaning its execution was
>pre-emptively multi-tasked in my Win95 environment and Delphi was 16-bit so it
>took over the machine.
Actually, Delphi2 runs it loops almost twice as fast as Delphi1 in a
32-bit environment. Check out last week's PC Week review. Even
though it sounded favorable to Delphi2 (which I liked :), I would
grade it a 68 from a scale of 1 to 100, 100 being an A+.
Mathew Gyokers Eliot
>Actually, it plays little games that make benchmarketing easy. For example, if
>you increment a variable in a loop, but subsequent to the loop you don't use it,
>the compiler simply skips the loop. Makes the benchmarketing numbers look really
>good, but it's not going to do much for you in the real world.
I've got to jump in here much as I'm loath to- it's doing what
optimizing compilers do- they dump code that doesn't make any difference.
It hasn't got anything to do with marketing- it's all about
getting your code to execute a little faster- how much faster
depends on how much dead code you write, sure 1 instruction doesn't matter,
a bunch more might.
If you don't like the optimizations when you're comparing, turn
them off, but you're doing a disservice to the compiler when you
benchmark without optimizations.
I can understand you wanting to defend your tool (PB) but I don't
think anyone here wants to hear you tell us how the optimizations
are nonsense.
If you don't understand how optimization works, then I'd suggest
finding some books on it, or about a year or so ago, there was a very
nice article in Dr Dobb's Journal about all the things that most
compilers will do to optimize code.
--
Paradox and Delphi Consultant. Member: Borland Delphi Technical Support
Most small questions answered for free!
Paradox Web Page: http://www.pagescape.com/fire/pdox/
My words are my own, I don't speak for Borland.
Bill Touchstone
>Dennis Courtney <DEN...@IADB.ORG> wrote:
>
>>as you put it? BTW, that "tricky thing the
>>compiler does" is called machine code.
>
>you increment a variable in a loop, but subsequent to the loop you don't use it,
>the compiler simply skips the loop. Makes the benchmarketing numbers look really
>good, but it's not going to do much for you in the real world.
What you have is an optimization technique. If a variable isn't used, why would
you put it in the loop? And if that were the only thing in the loop, why loop?
It also detects when code is placed in a loop that only needs to be calculated
once, it will move it out of the loop. In fact there are many optimizations
used in this compiler.
The compiler doesn't know a benchmark from 'real world'
code. So it will optimize application code just as well.
In fact, it lets programmers make stupid mistakes in less than optimal coding
techniques and can correct for them. This can be quite useful where a shop
standard opts for a more readable style and tends to cause the code to be less efficient. The compiler can greatly reduce those inefficiencies in the executable.
None of these optimizations are possible in an interpretive environment.
>
>>It all gets down to who we should believe - the
>>technical staff of major publications we've come
>>to rely on over the years or some guy in Alberta?
>
>Very mature, slamming someone because of where they live. And if you've been
>around at all you should know by now that you can't believe everything you read.
I think you lost the point here. It wasn't a slam against Alberta (a fine place
but way too cold for me). It was just a way of referring to you as being a
regular folk among us stating an opinion vs a number of people who have objectively
approached the problem and derived a (believed to be) scientific result. You
shouldn't let your feathers be ruffled here.
Craig Wagner
>>Actually, it plays little games that make benchmarketing easy. For example, if
>>you increment a variable in a loop, but subsequent to the loop you don't use it,
>>the compiler simply skips the loop. Makes the benchmarketing numbers look really
>>good, but it's not going to do much for you in the real world.
>
> I can understand you wanting to defend your tool (PB) but I don't
>think anyone here wants to hear you tell us how the optimizations
>are nonsense.
>
> If you don't understand how optimization works, then I'd suggest
>finding some books on it, or about a year or so ago, there was a very
>nice article in Dr Dobb's Journal about all the things that most
>compilers will do to optimize code.
As much as I appreciate your suggestion to further my education, I'm quite
comfortable with what an optimizing compiler does. I'd also like to point out
that I never said the optimizations are nonsense. As you aren't astute enough to
pick up my meaning from the original message, let me try again...
The simple point I was trying to make is that when comparing the processing
speed of two tools, then both tools need to actually perform the process which
is being timed. If one tool skips the process entirely because its compiler
decided the code did not need to be executed, then what you've compared in the
optimization features of the compiler, you have not compared which tool can
perform the process the fastest. If you don't understand that, then perhaps you
should pick up a few articles on what benchmarking is designed to do.
Robert Sandercott
>
> Dennis Courtney <DEN...@IADB.ORG> wrote:
>
> >> Bullshit, plain and simple. I've done tests myself between the two and to use
> >> the loaded phrase "a lot slower" is BS. Delphi benchmarks can be cooked due to
> >> some tricky things the compiler does.
>
> > Is it your position that the PowerBuilder code is
> >as fast as Delphi? I use PB, VB, C++ and Delphi
> >and I too have "done some tests" and I gotta tell
> >you Delphi is faster (and that ain't BS).
>
> But let's consider how that impacts the real world. In a loop which I executed
> 10,000,000 times, PowerBuilder 5.0 beta (build 107) took 45 seconds and Delphi
> 1.0 took 30 seconds. Even if we completely ignore the following two facts...
>
> 1. In a new release performance tuning is usually the last thing done (i.e.
> PowerBuilder 5.0 beta is probably not as fast as it's going to get).
>
> 2. The PowerBuilder 5.0 application was 32-bit, meaning its execution was
> pre-emptively multi-tasked in my Win95 environment and Delphi was 16-bit so it
> took over the machine.
>
> 0000015 seconds faster. Guess you're right, Delphi is faster. Then again, if it
> requires 1,000,000 iterations of a loop to generate a 1.5 second difference,
> does it really matter? Given the narrow margin of victory, I think I'll take the
> ease of PowerScript over Pascal.
>
> >compiler does" is called machine code.
>
> you increment a variable in a loop, but subsequent to the loop you don't use it,
> the compiler simply skips the loop. Makes the benchmarketing numbers look really
> good, but it's not going to do much for you in the real world.
>
> >technical staff of major publications we've come
> >to rely on over the years or some guy in Alberta?
>
> Very mature, slamming someone because of where they live. And if you've been
> around at all you should know by now that you can't believe everything you read.
> Craig Wagner | E-mail: wag...@spots.ab.ca
> Calgary, AB | Fidonet: 1:134/66
> (403) 271-7387 | Excrement occurs!
I am always amazed at how much emphasis people continually put on the
speed of one tool versus another. When choosing a new development tool,
the speed of the tool does not usually even make my top ten list.
Assuming the speed of a tool is within the same ballpark as other tools,
many other factors are far more important when rating tools. I would
typically consider factors such as scaleability (can it handle a large
application and large databases?), speed of developing the application,
learning curve, availability of third party add ons, links to other
software (openess) such as testing tools, version control software,
database connectivity etc. I also would place inheritance very high on
my list. This is the feature that is going to make your application
maintainable after you build and speed up your initial development time.
Am I able to add that logic to translate all my field labels to Italian
in one place and have all my forms in herit this new feature or do I
have to go and modify 200 forms individually.
The fact that a WHILE loop executes in 30 seconds on one tool and 45
seconds on another is almost irrelevant. Most applications are data
bound doing database access not sitting in a while loop. Since
computers double in power every 18 months the speed difference will
become half every year and a half. Anyways I have said way more than
anyone probably cares to hear! All I can say is that in my 10 years of
application development I have never been sorry that I didn't choose
tool A instead of tool B simply because tool A could execute a while
loop slightly faster. I would be much more interested in hearing
comments on the more major differences between Delphi and Powerbuilder.
Things such as stability, ease of development, flexibility,
inheritance, maintainability of code, lack of bugs etc.
Robert
Bill Touchstone
Hmmm....
I wonder who isn't understanding who here.
In programming, we try to develop algorithms that solve problems. The goal is
to get from the problem state to the solution state as quickly as possible.
You can use many tools do accomplish this. The tool that develops the fastest
executing algorithm wins. Whatever the means it uses. What you seem to be
objecting to is that some useless code got thrown out. I'm still not sure why
you would want useless code in your end product anyway.
To me, it makes no difference whether the code was thrown out by a programmer
or by a chunk of software... as long as it doesn't get executed in the final product.
Optimization is only one process a tool uses to develop a solution. The goal is to
make the solution be the fastest possible. Optimization goes a long way toward
that goal. All that matters is that the solution is correct. Given that, the
first one across the finish line wins.
You seem to think because you loaded up your model with useless code, all models
should be similarly bound.
The only time optimization would be unfair would be if it was not available to
standard applications. If it was designed to only improve benchmarks, then it
would be deceptive. That isn't the case. It will fix every chunk of bad code you
give it.
>---
>Craig Wagner | E-mail: wag...@spots.ab.ca
>Calgary, AB | Fidonet: 1:134/66
>(403) 271-7387 | Excrement occurs!
Bill Touchstone
ycc...@gate.net