Xbase++ benchmarking
Phil Barnett
Some benchmarking:
This benchmark is a function which determines the prime numbers under
1000. The sieve function was repeated 1000 times.
The residual CPU percentage with nothing running was 9%.
Compiler Processing Time CPU% .EXE Size
Summer '87 I gave up after 30 minutes. 11 165K
5.2 105.67 seconds 100 156K
5.3 61.13 seconds 100 182K
Xbase++ 57.79 seconds 100 38K
Platform: Windows NT Server 4.0 Service Pack 3
Here is the benchmark source:
(S'87 test was essentially identical, sans the 5.x stuff)
*--------------------
function main()
local j
local starttime
clear screen
qout( 'Benchmark Start' )
starttime := seconds()
for j := 1 to 1000
sieve()
next
qout( 'Elapsed time', seconds() - starttime )
return NIL
*--------------------
static function sieve()
local y
local x
local lPrime
local nStopHere
local aPrime := array( 169 )
local nPrimeCnt := 2
aPrime[ 1 ] := 1
aPrime[ 2 ] := 2
for x := 3 to 999 step 2
lPrime := .t.
nStopHere := sqrt( x )
for y := 3 to nPrimeCnt
if aPrime[ y ] > nStopHere
exit
endif
if x % aPrime[ y ] == 0
lPrime := .f.
exit
endif
next
if lPrime
aPrime[ ++ nPrimeCnt ] := x
endif
next
return NIL
---
Phil Barnett mailto:philb@iag~net <-anti spam replace ~ with .
WWW http://www.iag.net/~philb/
FTP Site ftp://ftp.iag.net/pub/clipper
NO PARKING!
Violators
will be Crushed
and Melted.
Robert Lamping
Dear Phil,
I tried your benchmark
On Windows 95 [4.00.950a], Pentium 133, 32 Mb RAM, I get the following
result.
Compiler Processing Time CPU% .EXE Size
5.3a 42.07 seconds --- 438K
Why do you think the processing time is less then your results?
My .Exe size is larger. I have the impression you use other link scripts
to minimize exe-size. Please give me a hint or show the link-scripts.
Kind regards,
Robert Lamping
Phil Barnett
>I tried your benchmark
>
>On Windows 95 [4.00.950a], Pentium 133, 32 Mb RAM, I get the following
>result.
>Compiler Processing Time CPU% .EXE Size
>5.3a 42.07 seconds --- 438K
>Why do you think the processing time is less then your results?
I have a Pentium 100 running a different operating system.
Accurate benchmarks are run on the same machine for comparison
purposes. The actual speed is of little importance and is machine
dependent.
>My .Exe size is larger. I have the impression you use other link scripts
>to minimize exe-size. Please give me a hint or show the link-scripts.
It was hand compiled and linked.
Clipper sieve /m /n /w
blinker fi sieve bli inc off
TSDing
Maybe you can put the code to test on the VO 2.0A-1 since it is
also a variant of the Clipper Language.
Phil Barnett wrote:
>
> Compiler Processing Time CPU% .EXE Size
>
> Summer '87 I gave up after 30 minutes. 11 165K
> 5.2 105.67 seconds 100 156K
> 5.3 61.13 seconds 100 182K
> Xbase++ 57.79 seconds 100 38K
VO 2.0A-1 ? ? ?
Regards
TSDing
Phil Barnett
On Sun, 14 Dec 1997 09:00:03 +0800, TSDing <din...@pc.jaring.my>
wrote:
>Maybe you can put the code to test on the VO 2.0A-1 since it is
>also a variant of the Clipper Language.
A distant cousin.
>Phil Barnett wrote:
>> Compiler Processing Time CPU% .EXE Size
>> Summer '87 I gave up after 30 minutes. 11 165K
>> 5.2 105.67 seconds 100 156K
>> 5.3 61.13 seconds 100 182K
>> Xbase++ 57.79 seconds 100 38K
> VO 2.0A-1 ? ? ?
I rather doubt it. I don't own VO.
Dave Pearson
On Sat, 13 Dec 1997 09:12:43 GMT, Phil Barnett <nu...@iag.net> wrote:
> Summer '87 I gave up after 30 minutes. 11 165K
> 5.2 105.67 seconds 100 156K
> 5.3 61.13 seconds 100 182K
> Xbase++ 57.79 seconds 100 38K
^^^^
What about the size of the support DLLs? A better benchmark here might be
the memory foorprint.
The above pretty much follows what I found with the Fibbonaci test I posted
a few days ago, xBase++ is faster a straight calculation. However, like I
said at the time, the suprising result was that xBase++ was slower than
Clipper 5.2e when a lot of function calls were taking place (if you recall I
had two functions for calculating Fib( n ), one iterative and one
recursive).
--
Take a look in Hagbard's World: | w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ | ng2html - The NG to HTML converter.
http://www.hagbard.demon.co.uk/ | eg - Norton Guide reader for Linux.
Free software, including........| dgscan - DGROUP scanner for Clipper.
Zoltan Gyorgypal
Phil Barnett wrote:
> Compiler Processing Time CPU% .EXE Size
>
> Summer '87 I gave up after 30 minutes. 11 165K
> 5.2 105.67 seconds 100 156K
> 5.3 61.13 seconds 100 182K
> Xbase++ 57.79 seconds 100 38K
Instructive results. Let me add another item:
Compiler Processing Time .EXE size
Clipper 5.2 (control) 94.47 seconds 145,232 bytes
Force 4.0 10.55 seconds 6,592 bytes
Test environment was Pentium 100, 16 Mb RAM, Windows NT Workstation 4.0
Service Pack 3.
There is no typo in the above data. For those who don't know yet: the
big difference is because Force is a pure native code compiler, the only
one in the xBase family. But no other problems with it <g>.
The benchmark source was adapted to Force from Phil's original, and is
shown below for comparison. I can send the executable if anyone wants to
try it himself (fortunately not too big).
#include system.hdr
proc sieve extern
function dbl sqrt extern
parameters const dbl nNumber
function int main
vardef
uint j
dbl starttime
enddef
clear
? "Benchmark Start"
starttime := dayseconds()
for j := 1 to 1000
sieve()
next
? "Elapsed time", dayseconds() - starttime
return( 0 )
endfunc
//-------------------
proc sieve static
vardef
uint y
uint x
logical lPrime
uint nStopHere
uint aPrime[ 170 ]
uint nPrimeCnt
enddef
nPrimeCnt := 2
aPrime[ 1 ] := 1
aPrime[ 2 ] := 2
for x := 3 to 999 step 2
lPrime := .t.
nStopHere := sqrt( x )
for y := 3 to nPrimeCnt
if aPrime[ y ] > nStopHere
exit
endif
if x % aPrime[ y ] == 0
lPrime := .f.
exit
endif
next
if lPrime
nPrimeCnt++
aPrime[ nPrimeCnt ] := x
endif
next
endfunc
--
Zoltan Gyorgypal, PhD
ENforce Developments
mailto:cs...@baybio.bay.u-szeged.hu
http://force.szolnet.hu
Phil Barnett
>Phil Barnett wrote:
>> Compiler Processing Time CPU% .EXE Size
>> Summer '87 I gave up after 30 minutes. 11 165K
>> 5.2 105.67 seconds 100 156K
>> 5.3 61.13 seconds 100 182K
>> Xbase++ 57.79 seconds 100 38K
>Instructive results. Let me add another item:
>Compiler Processing Time .EXE size
>Clipper 5.2 (control) 94.47 seconds 145,232 bytes
>Force 4.0 10.55 seconds 6,592 bytes
>Test environment was Pentium 100, 16 Mb RAM, Windows NT Workstation 4.0
>Service Pack 3.
If you'll send me the .EXE and source via email, I'd like to keep it
on hand for future tests, plus I'll run it and repost the above
results with it included.
Thanks for taking the time.
BTW, how does this test compare for Force 2 and 3?
tom leylan
>> Compiler Processing Time CPU% .EXE Size
>
>> Summer '87 I gave up after 30 minutes. 11 165K
>> 5.2 105.67 seconds 100 156K
>> 5.3 61.13 seconds 100 182K
>> Xbase++ 57.79 seconds 100 38K
>>Clipper 5.2 (control) 94.47 seconds 145,232 bytes
>>Force 4.0 10.55 seconds 6,592 bytes
I watch the goings on every so often and couldn't resist the challenge.
Clipper 5.2 (control) 67.18 seconds 169K
Delphi 2 1.42 to 1.49 seconds 164K
on a 133MHz Pentium. Perhaps somebody would like to verify it.
Before we get into silly arguments consider what you would say if somebody
wrote "in interpreted BASIC it runs in 5 minutes", I'll guess something along
the lines of "wow, you should use Clipper it's fast and powerful."
Why doesn't that argument hold when an easier, faster and more powerful tool
exists that just happens to not be Clipper?
unit test;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls,
Forms, Dialogs, StdCtrls;
type
TForm1 = class(TForm)
Button1: TButton;
lbTime: TLabel;
procedure Button1Click(Sender: TObject);
private
procedure Sieve;
end;
var
Form1: TForm1;
implementation
{$R *.DFM}
procedure TForm1.Button1Click(Sender: TObject);
var
j: integer;
starttime: TDateTime;
SHour, SMin, SSec, SMSec: Word;
EHour, EMin, ESec, EMSec: Word;
begin
DecodeTime( time, SHour, SMin, SSec, SMSec );
for j := 1 to 1000 do
Sieve;
DecodeTime( time, EHour, EMin, ESec, EMSec );
lbTime.Caption :=
IntToStr( ( ( ESec - SSec ) * 1000 ) + ( EMSec - SMSec ) );
end;
procedure TForm1.Sieve;
var
x, y: integer;
lPrime: boolean;
nStopHere: Double;
aPrime: array[ 1..169 ] of integer;
nPrimeCnt: integer;
begin
aPrime[ 1 ] := 1;
aPrime[ 2 ] := 2;
nPrimeCnt := 2;
x := 3;
while x < 999 do
begin
lPrime := True;
nStopHere := Sqrt( x );
for y := 3 to nPrimeCnt do
begin
if aPrime[ y ] > nStopHere then
break;
if ( x mod aPrime[ y ] ) = 0 then
begin
lPrime := False;
break;
end;
end;
if lPrime then
begin
Inc( nPrimeCnt );
aPrime[ nPrimeCnt ] := x;
end;
x := x + 2;
end;
end;
end.
Zoltan Gyorgypal
Phil Barnett wrote:
> >Clipper 5.2 (control) 94.47 seconds 145,232 bytes
> >Force 4.0 10.55 seconds 6,592 bytes
...
> If you'll send me the .EXE and source via email, I'd like to keep it
> on hand for future tests, plus I'll run it and repost the above
> results with it included.
Sure, I just sent these to your address.
> BTW, how does this test compare for Force 2 and 3?
Today's results:
Compiler Processing time .exe size
------------------------------------------------
Clipper 5.2 88.43 secs 145,920 bytes
Force 2.4e 9.37 secs 9,008 bytes
Force 4.0 9.23 secs 6,448 bytes
I linked differently, therefore the slight changes in the sizes since
yesterday. I guess the processing time is influenced by the current
workload of WinNT. Anyway, only the ratios are important.
FYI: there is no Force 3 published. Force 2.4e is the last publicly
available version, while 4.0 is right before going beta. BTW tester
applications are still accepted at the Force web site.
> Thanks for taking the time.
As you might guess, I have an interest in propagating Force. OTOH I like
Clipper, earlier played around a lot with it. Actually Force is not
necessarily to be taken as a competitor of Clipper. The new version,
4.0, can also be regarded as a tool _for_ Clipper.
Let me tell you what I mean. Many times it is necessary to put C modules
in a Clipper application, when some low level trickery is needed, or
when speed is critical. Now, Force also became suitable to link with
Clipper. Why is it any better than C? Well, it is not better, but
certainly much easier to learn/use for those who are used to the xBase
style. Force code looks pretty much how Clipper does, while this can't
be said about C.
As an example, I recently experimented with writing a simple OOP system
for Clipper. It is in pure Force, and solely uses clipper.lib internals
(that are not accessible from Clipper) for defining/using new classes
and objects. I will upload somewhere these sources as soon as Force 4.0
hits the shops, so anyone who wants to explore the Clipper OOP internals
using an understandable tool will be able to do it, for example for
designing a whole new OOP approach that works exactly how he likes it.
TIM AANONSEN
tom leylan wrote:
>
> >> Compiler Processing Time CPU% .EXE Size
> >
> >> Summer '87 I gave up after 30 minutes. 11 165K
> >> 5.2 105.67 seconds 100 156K
> >> 5.3 61.13 seconds 100 182K
> >> Xbase++ 57.79 seconds 100 38K
>
> >>Force 4.0 10.55 seconds 6,592 bytes
>
>
> Clipper 5.2 (control) 67.18 seconds 169K
> Delphi 2 1.42 to 1.49 seconds 164K
>
> on a 133MHz Pentium. Perhaps somebody would like to verify it.
>
> Before we get into silly arguments consider what you would say if somebody
> wrote "in interpreted BASIC it runs in 5 minutes", I'll guess something along
> the lines of "wow, you should use Clipper it's fast and powerful."
>
> Why doesn't that argument hold when an easier, faster and more powerful tool
> exists that just happens to not be Clipper?
>
Good Point.
Now how about some benchmarks showing some data handling
(searches, replaces, indexing, different RDD's, etc) after all these
languages were written for handling data, ASM is for
calculations.
--
Insanity is doing what you've always done, then expecting different
results!!
Jovan Bulajic
Phil Barnett <nu...@iag.net> wrote:
> This benchmark is a function which determines the prime numbers
> under 1000. The sieve function was repeated 1000 times.
Nice test, but mostlu useless <g>. I think we should compare speed of
database operations (read, write, append, seek, etc.), is there any
standardized set of database tests?
--
Jovan Bulajic
Belgrade, Yugoslavia
bul...@sezampro.yu
tom leylan
TIM AANONSEN <taan...@mail.datasys.net> wrote:
>Now how about some benchmarks showing some data handling
>(searches, replaces, indexing, different RDD's, etc) after all these
>languages were written for handling data, ASM is for
>calculations.
I'll claim, without having run any benchmarks, that Delphi will blow Clipper
out of the water on any test you can devise. There are technical reasons why
and among them is it's a native code 32-bit compiler. Delphi is also actively
being produced which means if it happened to be slower on something Borland
would likely improve it in the next version because there is a competitive
advantage gained by doing so.
On the flip side if Clipper could be sped up by a factor of 100% cutting the
60 seconds to 30 it wouldn't impact CA's bottom line at all. Nobody is buying
Clipper these days and the reasons have nothing to do with the speed of a
REPLACE.
Intel is fast at work on a 64-bit CPU, MS is no doubt working on a 64-bit
version of NT, Borland will obviously port Delphi, CA will clearly not
release a 64-bit version of Clipper.
If you want to try a simple benchmark post the Clipper code to extract all the
invoices (invoice number, date, total) for each client (client number, name)
and I'll post the one line SQL query.
When you're done we'll see how long it takes to change the order from client
number to client name. I'm planning on adding an ORDER clause to the SQL
query, I suspect that Clipper developers will add another index, rewrite,
recompile and redistribute the executable.
As for "ASM is for calculations" I never intend to start an argument but
having written 6502, Z-80 and 8086 assembler the last thing I want to do is
write floating point calculations with it.
As for benchmarks showing database speed... it's possible you missed the
obvious. When the client says "I want a window that shows the directory tree,
permits me to choose a .DBF file, displays the file in a grid and lets me
search by client last name" I would answer, "that's going to take me a few
minutes" the Clipper developer offers a quote of $2000 and suggests they can
deliver a test version in about a week.
If my solution took a minute per query I'd still be 2400 minutes ahead before
the Clipper app was delivered.
And here is the important point, it isn't "Delphi" that makes this possible I
could do it in VB or C++ also. Tools have improved since Clipper was
designed. Companies listened and learned and provided solutions to
business app development and no amount of claiming Clipper is the "fastest,
smallest, most robust" or any other thing that hasn't been true for years is
going to change that.
And lest there be some misunderstanding, I'm perfectly happy if every Clipper
developer remained in Clipper forever. More power to them...
Tom
Dave Pearson
On Tue, 16 Dec 1997 17:40:34 GMT, tom leylan <tle...@abest.com> wrote:
I was nodding away at everything you wrote Tom, until I hit this paragraph
and I had to double check that you were the author.
> As for benchmarks showing database speed... it's possible you missed the
> obvious. When the client says "I want a window that shows the directory
> tree, permits me to choose a .DBF file, displays the file in a grid and
> lets me search by client last name" I would answer, "that's going to take
> me a few minutes" the Clipper developer offers a quote of $2000 and
> suggests they can deliver a test version in about a week.
This is just plain wrong. If you are talking about what can be done with the
tool "out of the box", then yeah, I'd pretty much nod in agreement as you
say the above, however, if you are talking about doing the above with the
correct tools for each language (correct tools for Pascal, correct tools for
Clipper) then I'd have to disagree. Where I work, we've got the framework
for doing the above in a Clipper app in not too many lines of code. Perhaps
slightly more than the respective Delphi app, perhaps less, but it wouldn't
be a 2K one week+ solution.
However, getting onto the question of benchmarks, no, I don't think the
obvious was missed at all. Your paragraph above raises a *different* valid
point. The *obvious* question/problem with database benchmarks is "*What*
database?" The speed of development isn't the (only) issue for the end user
(in technical terms and speed of solution terms). I won't disagree that
there is an economic element to this, however, this isn't the place for such
a discussion, this is a comp.lang group which is, by definition, a technical
group, so forgive me if I allow that to pass to a better place. In terms of
getting the correct *technical* solution (that it, it works well, it is
secure, it is fast, etc) then benchmarking things like database access are
important for a specific solution.
But, like I said, the question then is "what database"? What do you
benchmark? Are you going to benchmark against some local access database?
Some form of database server? What sort of server? What sort of hardware?
What sort of connection? What sort of network card? What sort of.....
(For general consumption, not in direct response to Tom) Benchmarks are fun,
but that is it. They serve no other purpose *unless you do them yourself*
and *in the context of the solution you are attempting to provide*. And,
even then, you have to ask the right questions and draw the correct
conclusions. Anyone why thinks this thread is anything serious is missing
the point and missing it in a big way. To see how misleading all of this is
look at the Fibonacci benchmark I posted the other day. Depending on which
way you look at it, Clipper blows xBase++ out of the water. To think in
those terms would be to mislead yourself.
This is why I think Tom was partly wrong in his post (at least in the quoted
paragraph). He correctly showed that at the end of the day benchmarks don't
count for much "in the real world", I'm just suprised that he attempted to
conclude his post with another bogus benchmark that appears to be based on
suspect data. :-)
Phil Barnett
On 16 Dec 1997 12:07:38 GMT, "Jovan Bulajic" <bul...@sezampro.yu>
wrote:
>Phil Barnett <nu...@iag.net> wrote:
>> This benchmark is a function which determines the prime numbers
>> under 1000. The sieve function was repeated 1000 times.
>Nice test, but mostly useless <g>.
I think it's important to know how fast the guts run before figuring
out how fast the interfaces run. I agree that it may not mean much,
but it does reveal a lot about the raw processing speed any language
can provide.
>I think we should compare speed of database operations (read, write, append, seek,
>etc.), is there any standardized set of database tests?
Please feel free to implement and benchmark and publish!
TIM AANONSEN
Val wrote:
>
> We're talking about software here, folks. It's entirely possible to do
> the same thing over and over and occasionally get different results!
>
> Ray
SO..
That explains why my code crashes when there is a full moon! =)
Sean Webb
Tom leylan made some remarks basically ( the original post got accidentally lost
in the trash can)
using delphi & SQL to claim that it will blow away clipper/xbase++
and be faster to modify.
1) clipper is primarily (but not soley) used for dbase manipulation
so comparing this to delphi/sql performance is non valid.
2) A valid test would be to compare the performance of
delphi dbf manipulation to that of clipper/xbase
3) Different results again if you bypassed the BDE and used halcyon with
delphi for manipulating DBFS.
4) Has anyone tried comparing the performance of clipsql vs delphi sql ??
5) And BTW tom , what sql database would you be testing on.
Bet that if your using Delphi + M$ sql server i'd beat the pants off you
using oracle + Delphi
So what ....<g>
6) Are you aware tom that
Clipper can be used with btrieve (much faster than DBFs , transaction
processing ,rollbacks etc)
And clipper + btrieve 6.1x combination could possibly blow delphi
and SQL out the water ?? After all SQL is not the fastest method for
accessing data on this planet , just one of the most convenient.
You can only compare like with like.
--
Sean Webb , Spyder Computing
Security & Risk Management Systems (Shopping Malls, Waterfronts, Guarding
Companies, CBD's ) . Fire & Rescue database applications
Marina Booking Systems , POS developments.
Personal Home page:- http://users.iafrica.com/s/sp/spwebb
The Graphical Gnome
In article <676eej$o...@news.abest.com>, tle...@abest.com (tom leylan) wrote:
>TIM AANONSEN <taan...@mail.datasys.net> wrote:
>>Now how about some benchmarks showing some data handling
>>(searches, replaces, indexing, different RDD's, etc) after all these
>>languages were written for handling data, ASM is for
>>calculations.
>
>I'll claim, without having run any benchmarks, that Delphi will blow Clipper
>out of the water on any test you can devise. There are technical reasons why
>and among them is it's a native code 32-bit compiler.
I strongly doubt that. I work in Both Clipper and Delphi 2.0/3.0.
If I try to search for a string in a 70.000 records database. I'm pretty sure
that Clipper will win.
An other reason for using Clipper is that it is still fast on a Laptop 386
instead of a Desktop P166.
Don't compare to much. Try to get the BEST tools, not the fastest.
The Graphical Gnome (r...@ktibv.nl)
Sr. Software Engineer IT Department
-----------------------------------------
The Unofficial Delphi Developers FAQ
http://www.gnomehome.demon.nl/uddf/index.htm
Gordon Hamm
I agree 100%.. its time that we as Clipper heads let the "Glory Days" go..
I mean , move on..
Delphi rocks, and with Halcyon, I have the best of both worlds.. Delphi and
Clipper..
http://www.grifsolu.com
The apps are quick to develop, 32 bit, no runtimes, lean and mean..
Do I sound like a preacher ?? yup.. as they say, I finally saw the light..
--
Gordon Hamm
Voice Data Systems Inc.
Astoria Communications
360-686-8315
tom leylan wrote in message <676eej$o...@news.abest.com>...
>TIM AANONSEN <taan...@mail.datasys.net> wrote:
>>Now how about some benchmarks showing some data handling
>>(searches, replaces, indexing, different RDD's, etc) after all these
>>languages were written for handling data, ASM is for
>>calculations.
>
>I'll claim, without having run any benchmarks, that Delphi will blow
Clipper
>out of the water on any test you can devise. There are technical reasons
why
>As for benchmarks showing database speed... it's possible you missed the
>obvious. When the client says "I want a window that shows the directory
tree,
>permits me to choose a .DBF file, displays the file in a grid and lets me
>search by client last name" I would answer, "that's going to take me a few
>minutes" the Clipper developer offers a quote of $2000 and suggests they
can
>deliver a test version in about a week.
>
tom leylan
spw...@iafrica.com (Sean Webb) wrote:
>Tom leylan made some remarks basically ( the original post got accidentally
> lost in the trash can) using delphi & SQL to claim that it will blow away clipper/xbase++
>and be faster to modify.
More than a claim... lest anybody forget I used to work for Nantucket and I
wrote a book on Clipper development. If I worked 20 years with dBASE and
claimed Clipper was faster you'd quote me all over the planet... well I've
used Clipper since it arrived, used 5.x for one year before it was released to
the general public and I'm as qualified as anybody to determine what Clipper
can and can't do.
Clipper doesn't "suck" it's a DOS development tool with a procedural language
based primarily on the dBASE language. You can wish that it was more but then
I could wish that Delphi cured cancer. It doesn't.
>1) clipper is primarily (but not soley) used for dbase manipulation
> so comparing this to delphi/sql performance is non valid.
The reason that comparisons are "valid" is that companies don't pay for "dbase
manipulation" they pay for results. They don't even pay for query times
unless they get extraordinarily long. They pay for development and
maintenance and you'd have to program an awfully long time in Clipper do
access the internet... I am however willing to be proven wrong. Post your
Clipper code for accessing mail thru SMTP, I'll whip something together in
Delphi and we can compare the number of hours spent.
>2) A valid test would be to compare the performance of
> delphi dbf manipulation to that of clipper/xbase
Again... I like you Sean but nobody really cares about .DBF manipulation. Ask
CA if they care about .DBF manipulation, ask any large company.
>3) Different results again if you bypassed the BDE and used halcyon with
> delphi for manipulating DBFS.
Different results... okay, and your point would be?
>4) Has anyone tried comparing the performance of clipsql vs delphi sql ??
Who cares? If DingleSQL for DOS is twice as fast as Delphi out of the box
I'll buy DingleSQL/32 for Windows.
>5) And BTW tom , what sql database would you be testing on.
> Bet that if your using Delphi + M$ sql server i'd beat the pants off
> you using oracle + Delphi
> So what ....<g>
Again I'm at a loss to figure out what you mean? If you personally can beat
the pants off of anybody using Clipper and your customers want DOS-based apps
then you're all set. I'm not recommending Delphi I'm stating a fact, it is
generally more powerful, at least as reliable, it is object-oriented, it is a
native code compiler, the tools that are included are great, it generates
Win'95 and NT applications. Are you suggesting I've lied anywhere?
>6) Are you aware tom that
> Clipper can be used with btrieve (much faster than DBFs , transaction
> processing ,rollbacks etc)
> And clipper + btrieve 6.1x combination could possibly blow delphi
> and SQL out the water ?? After all SQL is not the fastest method for
> accessing data on this planet , just one of the most convenient.
Gee... I'm betting you could explain that to the VO folks and have them jump
right on back to Clipper. Heck... you know what I'm thinking? I'm thinking
you post a small ad in DBMS explaining to the people who license Oracle how
the just get Btrieve and Clipper and there are no problems.
I'll let you in on a secret Sean... One day you will pick up a Window-hosted
language and when doofuses explain how much more productive they are using
their DOS compiler and how you can't do anything they can do you'll gaze into
the sky and just wonder where these people come from.
> You can only compare like with like.
No you can't. A business can compare ground transportation with air
transportation they can compare 16-bit DOS implementations against 32-bit
Windows implementations. They want a job done and if they want to preview
reports with imbedded graphics before they print then you can bark all you
want about the unfair comparison or reference ClipPreviewReport-O-Matic from
BuzzWare but it isn't likely to make a lasting impression. It might...
somebody might prefer to spend 2000 hours reinventing the wheel but
personally I doubt it.
The future is here. When you join it you'll wonder why I even bothered to
post a reply.
tom leylan
r...@ktibv.nl (The Graphical Gnome) wrote:
>tle...@abest.com (tom leylan) wrote:
>>I'll claim, without having run any benchmarks, that Delphi will blow Clipper
>>out of the water on any test you can devise. There are technical reasons why
>>and among them is it's a native code 32-bit compiler.
>I strongly doubt that. I work in Both Clipper and Delphi 2.0/3.0.
Well okay. I suggest it will, you suggest it won't.
>If I try to search for a string in a 70.000 records database. I'm pretty sure
>that Clipper will win.
Actually you probably mean if you open a 70,000 record .DBF file. The last
job I was working on had 1 million+ record .DBF files, I'm not afraid of large
files. One SQL system had 90+ tables. What you might want to do is open 90
separate .DBF files (and their indexes), set relations and run some custom
code to list all overdue invoices.
You might search for a string I haven't found too many companies who
operate on the "searching for a string" business model.
What I'm trying to say is, let's say you can find an arbitrary string 10 times
faster than I can, how much closer does that make them to finishing a business
application?
>An other reason for using Clipper is that it is still fast on a Laptop 386
>instead of a Desktop P166.
You can use S'87 on an 8086 with a 5 MB hard drive. Probably should have
reconsidered the upgrade to 5.0.
>Don't compare to much. Try to get the BEST tools, not the fastest.
If you don't compare I wonder how you find the BEST tools. Oh, it's just
Clipper because you use it right? Not like if you used Paradox you wouldn't
be assaulting us all with how dumb we were not to recognize the power of
Paradox.
Look if you're sold on Clipper I'm not hear to change your mind, I'm not here
to foist a tool on you. I'm speaking to the last few developers still using
DOS who might be looking to write ActiveX components or interpret HTML or
access mail servers or solve any number of current business problems.
I don't CARE if you use DOS but please don't try and pretend you can write a
mouse-driven scrolling window in Clipper faster than anybody's 10 year old
brother can write one in Delphi or VB. It isn't true.
Do you drive a Volkswagon? Don't tell me it's the best car in the world!
And BTW, ignore the benchmark... unless Clipper won then of course it proves
what we all know.
Dave Pearson
On Wed, 17 Dec 1997 19:31:10 GMT, tom leylan <tle...@abest.com> wrote:
> Look if you're sold on Clipper I'm not hear to change your mind, I'm not
> here to foist a tool on you. I'm speaking to the last few developers
> still using DOS who might be looking to write ActiveX components or
> interpret HTML or access mail servers or solve any number of current
> business problems.
Then, with all due respect Tom, you are in the wrong Usenet group. Last time
I looked comp.lang.clipper was just that, a Usenet group for programming in
the Clipper language and it's derivatives. It isn't a DOS advocacy group, it
isn't a Windows advocacy group, it isn't a Delphi advocacy group, it isn't a
OO advocacy group, it isn't a <InsertSomethingYouAreUsingNow> advocacy
group. It is a group for programming in the Clipper language. That can take
in DOS, Windows, OS/2 and Unix to name some platforms.
Frankly I'm suprised after reading your current crop of posts. I'm sure that
you, above all people, can recognise that some solutions to current business
problems still use and/or require good old DOS. Love it or hate it, some of
us still have to live with it. No matter your view, it is a fact of life.
Can I respectfully suggest that the advocacy be taken someplace else? By and
large, you are "preaching to the converted" anyway. You yourself are proof
that you don't have to be a pure DOS die-hard to hang out in this group. So
people are having some fun comparing the exec speed of the currently
available Clipper derived compilers, so what? I'd say that is on-topic and
relevent to this group, far more on topic that Delphi code and
Delphi/Windows advocacy.
Tom, I'm very happy that you've found a tool that will allow you do solve
the business problems you are presented with (as it happens, it is one of
the tools we are considering for the next generation of our products),
however, the world is wider than your customer base and the problems to be
solved are more diverse than the specs you have on your desk right now. I'm
sure you can respect and understand that.
Anyway, must go, I've got some paying DOS work to get back to.... :-)
Dave Pearson
On Wed, 17 Dec 1997 19:18:57 GMT, tom leylan <tle...@abest.com> wrote:
> The reason that comparisons are "valid" is that companies don't pay for
> "dbase manipulation" they pay for results.
Granted.
> They don't even pay for query times unless they get extraordinarily long.
I'll sort of go with this too.
> They pay for development and maintenance
True.
> and you'd have to program an awfully long time in Clipper do access the
> internet... I am however willing to be proven wrong.
...and then it falls down. What kind of "comparison" is this? Sure,
*CA*-Clipper would not be the best tool to use if you want to develop
something that does internet connectivity, you'd be mad to think so. But,
this is a non-argument. The same could be said about using Delphi or VB or
VO to write a Linux device driver. It is a pointless statement. Look at the
problem, then consider the solutions. What does "access the internet" mean?
What kind of access, what do you want to do with that access? It simply
doesn't make sense and doesn't say anything about anything.
> Post your Clipper code for accessing mail thru SMTP, I'll whip something
> together in Delphi and we can compare the number of hours spent.
I assume you mean sending? Well, not that I'd recommend it, but something
(error checks aside) like this would be a ugly hack:
----------------------------------------------------------------------------
Function SendMail( cFrom, cTo, cSubject, cSmartHost, cText )
Local cTmpFile := UniqueName()
memowrit( cTmpFile, cText )
swpruncmd( "sendmail -f " + cFrom + " -s " + '"' + cSubject + '"' +;
" -F " + cTmpFile + " -t " + cTo + " -r " + cSmartHost )
ferase( cTmpFile )
Return( NIL )
----------------------------------------------------------------------------
I'm sure one of the other Clipper related tools and/or compilers would
manage a far cleaner job of it, for example VO, xBase++ or FlagShip (not to
mention Clip4Win or FiveWin).
Now, please, don't anyone read that as "see, it can be done quickly in
Clipper", that isn't my point. My point is that Tom has picked out an
example loaded in favour of the point he is trying to make.
Talking about the right tool to "access the internet" and pointing that
Clipper (read CA-Clipper here) isn't it is like talking about "painting" and
pointing out that a spanner isn't the right tool for the job (while, at the
same time, the chap in the hardware store is looking blankly at you
wondering if, by "painting" you mean you want to paint a landscape, or your
house, or your car). Personally, I'd want to pin the spec down a little more
before I chose the platform and the tool. Then again, perhaps that is just
me, being technical in a techy group. :-)
tom leylan
da...@hagbard.demon.co.uk wrote:
>The same could be said about using Delphi or VB or
>VO to write a Linux device driver. It is a pointless statement. Look at the
>problem, then consider the solutions. What does "access the internet" mean?
>What kind of access, what do you want to do with that access? It simply
>doesn't make sense and doesn't say anything about anything.
Actually Dave the same couldn't be said about Delphi or VB. Do you think the
distance between DOS database apps, Windows database apps and Internet
database apps is wide but the similarity to Linux device drivers is obvious?
Dave, please you win. You care so desperately I can't stand it. Yes,
everybody who uses Clipper today is going to be writing Linux drivers next
week and nobody will be writing Windows database apps.
>I assume you mean sending? Well, not that I'd recommend it, but something
>(error checks aside) like this would be a ugly hack:
Yeah you're hired that's what everybody is looking to do. You basically tell
the client to use MS Word or their favorite Windows editor and then run your
Clipper app to send it. Was there a reason you didn't just use a DOS batch
file to redirect the thing?
>I'm sure one of the other Clipper related tools and/or compilers would
>manage a far cleaner job of it, for example VO, xBase++ or FlagShip (not to
>mention Clip4Win or FiveWin).
Then run the prime number benchmark on VO, Clip4Win and FiveWin and lets get
back to the original topic.
>Talking about the right tool to "access the internet" and pointing that
>Clipper (read CA-Clipper here) isn't it is like talking about "painting" and
>pointing out that a spanner isn't the right tool for the job (while, at the
>same time, the chap in the hardware store is looking blankly at you
>wondering if, by "painting" you mean you want to paint a landscape, or your
>house, or your car). Personally, I'd want to pin the spec down a little more
>before I chose the platform and the tool. Then again, perhaps that is just
>me, being technical in a techy group. :-)
I already said you won so I'll leave you to bask in the accolades that only a
true defender of the faith deserves.
I remain dumbfounded... oh, and I've got a new jerk to add to my list.
tom leylan
da...@hagbard.demon.co.uk wrote:
>Then, with all due respect Tom, you are in the wrong Usenet group. Last time
>I looked comp.lang.clipper was just that, a Usenet group for programming in
>the Clipper language and it's derivatives.
Like all newsgroups however there is room for honest discussion of
thealternatives among "members" of the group. I have yet to read a newsgroup
on any subject that didn't occasionally field questions on alternative
products, languages and operating systems.
I'm a Clipper developer after all... it says so on my web page and that's what
I'm currently being paid to do.
>Frankly I'm suprised after reading your current crop of posts. I'm sure that
>you, above all people, can recognise that some solutions to current business
>problems still use and/or require good old DOS. Love it or hate it, some of
>us still have to live with it. No matter your view, it is a fact of life.
Not nearly as surprised as I am. There is a difference between suggesting the
use of Clipper as a solution to a "DOS-based" problem and pontificating about
how Clipper is better than everything or that the language is somehow state of
the art, DOS is better than Windows, etc., etc.
Discussion groups are for "discussions" right? If you're just selling Clipper
then I respectfully ask you to move to the alt hierarchy. You can't start
alt.politics.democrats (for instance) and feign surprise when the occasional
Republican chimes in when you sit around and chide how "dopey" they are.
>Can I respectfully suggest that the advocacy be taken someplace else?
You can respectfully do whatever you like. I'm not advocating anything, nor
does anybody who says they like a particular editor, linker or 3rd party
library.
>By and large, you are "preaching to the converted" anyway.
It sounds great but I'm not preaching. What is it about discussion that
bothers you so much? Did you do this on the Compuserve forum when things
didn't go your way? What's the deal no room for legitimate alternatives in
the world anymore?
>Tom, I'm very happy that you've found a tool that will allow you do solve
>the business problems you are presented with (as it happens, it is one of
>the tools we are considering for the next generation of our products),
>however, the world is wider than your customer base and the problems to be
>solved are more diverse than the specs you have on your desk right now. I'm
>sure you can respect and understand that.
Appreciate your thoughts. By the same token lots of people who use Clipper
and frequent this group are seeking alternatives. They often prefer to get
opinions from people they are familiar with, perhaps whose opinions they can
trust and from people who likely have similar business problems to solve.
I think you'd find it hard to convince most Clipper developers that I'm
notfamiliar with Clipper as a solution to business development problems and
that my use of any particular product for those problems that warrant Windows
solutions would be inapplicable to them.
>Anyway, must go, I've got some paying DOS work to get back to.... :-)
Me too. It's just if you posted something I wouldn't have bothered to ask you
to leave... nearly forgot... :-)
Ron Cherry
Phil Barnett wrote:
>
> This benchmark is a function which determines the prime numbers under
> 1000. The sieve function was repeated 1000 times.
I have never written a function to look for prime numbers before, but in
trying out your code in Clipper, the array needed to be sized to 501
instead
of 169. So I have a question about the following lines:
if x % aPrime[ y ] == 0
lPrime := .f.
exit
endif
Shouldn't that be "if x % aPrime[ y ] <> 0" ? (notice the <> instead
of ==)
Seems to me that if there is a remainder, it can't be a prime ?
Ron Cherry
Remove KILLSPAM. from address to return email to me (not necessary in
NG's).
Mike Taylor
Boys! Chill out! no need to get personal here... They are both just
tools!
I have been married to xBase since dBase II on CPM/OS, and used Clipper
since it was first released. I had a 4-digit Nantucket registration
number, and the first one was '0', but I also got Delphi.
As far as the OOP Windoze world is concerned, Delphi is the best of the
lot. And it does develop fast - faster than developing in Clipper. But
there are still places where DOS is the ideal thing to use - that's why
lots of accounting prgs have a DOS data-entry module to feed the
databases for the windows reporting/modeling mods. And Clipper does run
fast and on small machines.
The only problem is, how many people are willing to pay for new DOS
development? (Not too many as compared to those willing to pay for new
development for the Windoze platforms...)
C'ya,
Mike
--
mailto:mta...@vcnet.com - Mike Taylor
http://www.vcnet.com/mtaylor/Default.htm - SoCal Quail Unlimited Home
Page
Craig Veal
The jerk comment was uncalled for! If you want to participate in a
discussion or a religious debate that's fine. Leave the name calling to
the 12 year old kids.
If you can't say something nice, don't say anything.
tom leylan wrote:
> I remain dumbfounded... oh, and I've got a new jerk to add to my list.
>
Craig
Ross McKenzie
Gordon Hamm wrote:
>
> I agree 100%.. its time that we as Clipper heads let the "Glory Days" go..
> I mean , move on..
>
> Delphi rocks, and with Halcyon, I have the best of both worlds.. Delphi and
> Clipper..
> http://www.grifsolu.com
>
> The apps are quick to develop, 32 bit, no runtimes, lean and mean..
>
> Do I sound like a preacher ?? yup.. as they say, I finally saw the light..
>
> --
> Gordon Hamm
OK Gordon,
Money where the mouth is <g>. Would you care to present some
benchmarking times/tasks for your combination. I am sure there are many
here who woyuld like to see what you and yours can do.
Best wishes for Christmas,
Ross McKenzie
Melbourne Australia
tom leylan
ro...@sencon.com wrote:
>Money where the mouth is <g>. Would you care to present some
>benchmarking times/tasks for your combination. I am sure there are many
>here who woyuld like to see what you and yours can do.
You gotta be kidding Ross. I was just asked to stop posting here and all I
did was post the results of a simple timing test.
Anybody who honestly posts anything positive about Delphi or VB or any
non-Clipper related product is going to face a barrage of crap. We've all
seen it a hundred times with VO... smartest guy in the world using Clipper
becomes the dumbest ass on Earth the moment he didn't choose VO.
Smartest VO developer on the planet became the lowliest sucker in the universe
the moment he switched from VO to something else.
It's religion and religion is all about faith not facts.
Pick up a copy of Delphi and test it out and post your results here. At least
they won't be biased as our opinions obviously are. Oh, unless you like it in
which case, join the crowd... people who used to be smart and trustworthy and
are now ignorami.
I gotta go.. you guys depress me too much.
Tom
Ross McKenzie
tom leylan wrote:
>
> ro...@sencon.com wrote:
>
> >Money where the mouth is <g>. Would you care to present some
> >benchmarking times/tasks for your combination. I am sure there are many
> >here who woyuld like to see what you and yours can do.
>
> You gotta be kidding Ross. I was just asked to stop posting here and all I
> did was post the results of a simple timing test.
overwrought comments deleted ...
> I gotta go.. you guys depress me too much.
>
> Tom
Tom,
Sorry that you didn't notice that I was addressing Gordon Hamm. I have
no beef with you, so chill out please.
Like many others, I too am considering the available paths for the
future. Gordon has, on one or two occasions, made a passing comment
(mild enough?) about the Delphi and Halcyon duo. I would like some real
life info from someone who is obviously using that combination.
I am also considering VB5 + Artemis and would value some insights from
equally passionate users of that combination.
So Gordon, have you got any examples? They don't have to be rockhard
bench tests either.
Best wishes to all, including Tom
Ross McKenzie
Melbourne Australia
Dave Pearson
On Wed, 17 Dec 1997 23:13:07 GMT, tom leylan <tle...@abest.com> wrote:
> >The same could be said about using Delphi or VB or VO to write a Linux
> >device driver. It is a pointless statement. Look at the problem, then
> >consider the solutions. What does "access the internet" mean? What kind
> >of access, what do you want to do with that access? It simply doesn't
> >make sense and doesn't say anything about anything.
>
> Actually Dave the same couldn't be said about Delphi or VB. Do you think
> the distance between DOS database apps, Windows database apps and Internet
> database apps is wide but the similarity to Linux device drivers is
> obvious?
No, I don't, and you know that anyway. The point I'm making is that, IMHO
(and yours if I understand you correctly) you'd be insane to attempt to
write something that has full access to the internet in bog-standard
Clipper. All I was adding to that was the point that using that as an
example of why Clipper isn't much cop (and I mean all compilers/tools that
are Clipper derivative) just doesn't make sense. Hence the exaggerated gulf
in abilities.
> Dave, please you win. You care so desperately I can't stand it.
Huh? Care about what? The only thing I care about is that the correct tool
is used for the correct job. I've not said anything about your choice of
tool or your choice of job. All I've commented on is some of the conclusions
you draw because of your current choice of tool.
> Yes, everybody who uses Clipper today is going to be writing Linux drivers
> next week and nobody will be writing Windows database apps.
Tom, Tom, calm down mate. You appear to be making the mistake of thinking
I'm defending Clipper. I'm not. Go re-read what I've been saying but this
time assume I'm not in some kind of advocacy mode. The only vested interest
I've got in DOS/Clipper is that people still pay me to develop with that
tool and for that platform. Personally I'd sooner be elsewhere, Delphi would
be one good choice, Perl hacking for U*ix boxes would be another, Java
hacking would be another. I just love languages, programming and mucking
around with computers in general. Please don't make the mistake of thinking
I'm some kind of Clipper/DOS advocate. However, when I'm hanging out in
comp.lang.clipper, I talk about Clipper. Is that so unreasonable?
> >I assume you mean sending? Well, not that I'd recommend it, but something
> >(error checks aside) like this would be a ugly hack:
>
> Yeah you're hired that's what everybody is looking to do. You basically
> tell the client to use MS Word or their favorite Windows editor and then
> run your Clipper app to send it. Was there a reason you didn't just use a
> DOS batch file to redirect the thing?
<SIGH> Tom, please, where is your sense of humour? I even *STATED* that is
wasn't to be taken as a serious example of sending mail via an SMTP smart
host. Hell, I even pointed out the major flaw with it, no error checkimg,
what happens if the smart host isn't there right now? Do we abort, do we do
our own local spooling, do we have a separate thread to monitor the spool?
Yet again, I'll state, I *agree* that (CA-)Clipper isn't the language to use
if you want to write an application that is internet aware. However, I was
also pointing out that "all the world isn't the Internet". For example, very
few of out customers know what the Interet is, let alone have or need a
connection.
> >Talking about the right tool to "access the internet" and pointing that
> >Clipper (read CA-Clipper here) isn't it is like talking about "painting"
> >and pointing out that a spanner isn't the right tool for the job (while,
> >at the same time, the chap in the hardware store is looking blankly at
> >you wondering if, by "painting" you mean you want to paint a landscape,
> >or your house, or your car). Personally, I'd want to pin the spec down a
> >little more before I chose the platform and the tool. Then again, perhaps
> >that is just me, being technical in a techy group. :-)
>
> I already said you won so I'll leave you to bask in the accolades that
> only a true defender of the faith deserves.
<SIGH> Won? Won what? Defend? Defend what? I'm not defending anything. If
you think I'm defending anything then I suggest you go back and read my post
wth an open mind instead of assuming from the onset that anyone who posts a
followup must be attacking the core of your business plan and disagreeing
with the one true Leylan way.
Oddly, if you did correctly read my post, you should find that, if anything,
we violently agree. The only difference is I'm saying that given context of
the problem area you are coming from, (CA-)Clipper is, for the most part, an
irrelevance. Other implementations of the Clipper language are not, or do
you disagree with that?
> I remain dumbfounded... oh, and I've got a new jerk to add to my list.
Personal attacks are beneath you Tom.
Dave Pearson
On Thu, 18 Dec 1997 03:01:53 GMT, tom leylan <tle...@abest.com> wrote:
> >Money where the mouth is <g>. Would you care to present some
> >benchmarking times/tasks for your combination. I am sure there are many
> >here who woyuld like to see what you and yours can do.
>
> You gotta be kidding Ross. I was just asked to stop posting here and all
> I did was post the results of a simple timing test.
I don't recall seeing anyone ask you to stop posting stuff like that. I, for
one, was very interested in the code your posted and the results you
got. True, Delphi is off-topic for this group, but I'm sure many of us in
here are interested in what can be done with it from a ex-Clipper-head
perspective, it is one of the respected "next steps".
> Anybody who honestly posts anything positive about Delphi or VB or any
> non-Clipper related product is going to face a barrage of crap. We've all
> seen it a hundred times with VO... smartest guy in the world using Clipper
> becomes the dumbest ass on Earth the moment he didn't choose VO.
Tom, I think very few people have a problem with long respected members of
this group going "Delphi is the way to go when moving to Windows". I know
that some people have a problem when long respected members of this group do
the same but also dump on those who havn't made the move yet. Consider the
difference.
> Pick up a copy of Delphi and test it out and post your results here. At
> least they won't be biased as our opinions obviously are. Oh, unless you
> like it in which case, join the crowd... people who used to be smart and
> trustworthy and are now ignorami.
Tom, I'm sure that many of the long timers in comp.lang.clipper will join me
in saying that your posts are/were among those that we made a point of
reading. Hence my current suprise. The fact is, you don't have to dump on
anyone to show that your current solution is a good one (many of us know
this anyway). There is a big difference between "I've started using X as an
addition to my toolbox, it is neat", and "I've replaced my toolbox with X, I
can't believe you guys are still using that old stuff, what are you all
thinking?". Guess which way your current crop of posts are reading?
DOS/Clipper maybe a thing of the past for your, please don't dump on those
of us who still deal with it.
Dave Pearson
On Wed, 17 Dec 1997 23:23:12 GMT, tom leylan <tle...@abest.com> wrote:
> >Then, with all due respect Tom, you are in the wrong Usenet group. Last
> >time I looked comp.lang.clipper was just that, a Usenet group for
> >programming in the Clipper language and it's derivatives.
>
> Like all newsgroups however there is room for honest discussion of
> thealternatives among "members" of the group.
Yet again, we agree (I'll leave it as an exercise for the reader to work out
if calling someone a "jerk" is part of honest discussion <g>).
> I have yet to read a newsgroup on any subject that didn't occasionally
> field questions on alternative products, languages and operating systems.
Again, we agree. Indeed, comp.lang.clipper is well suited to this
considering the range of platforms the language can be used on.
> I'm a Clipper developer after all... it says so on my web page and that's
> what I'm currently being paid to do.
Snap.
> Not nearly as surprised as I am. There is a difference between suggesting
> the use of Clipper as a solution to a "DOS-based" problem and
> pontificating about how Clipper is better than everything or that the
> language is somehow state of the art, DOS is better than Windows, etc.,
> etc.
Again, I agree. Please show me where I've stated that DOS is better than
Windows or that Clipper is a state of the art language. As has happeed in
the past (the great centered-text/OO/Wadlow debate springs to mind) I can
only assume you are confusing me with someone else. Please don't confuse me
with someone who thinks that Clipper is the be-all and end-all of software
development.
> Discussion groups are for "discussions" right?
No argument here.
> If you're just selling Clipper then I respectfully ask you to move to the
> alt hierarchy.
Again, I think you are confusing me with someone else. Go back thru the
thread and show me where I'm selling Clipper. I'm not. What I have done is
show suprise at some of the statements you've made that sounded vaguely
anti-Clipper or anti-DOS, mostly when they've been backed up with facts
given in a context of the kind of business problems that are very well
suited to an environment with good database server access and good internet
access (not necessarily Windows).
> >Can I respectfully suggest that the advocacy be taken someplace else?
>
> You can respectfully do whatever you like. I'm not advocating anything,
> nor does anybody who says they like a particular editor, linker or 3rd
> party library.
Tom, I, and I guess many others, are very interested to hear and read about
your experiences with Delphi and other tools, even more so from a Clipper
migration POV. That isn't what I'm commenting on, and you know it. I'm
commenting on things like:
<676eej$o...@news.abest.com>
I'll claim, without having run any benchmarks, that Delphi will blow Clipper
out of the water on any test you can devise.
Which, on the surface, makes perfect sense, but hides a number of facts. For
example, how about the benchmark that includes running the same code,
native, in DOS, OS/2, Win95, WinNT and Un*x. Now, at this point, please
don't make the mistake of thinking I'm "selling Clipper". I'm not. I'm
simply asking for the context in which you wish to benchmark. You can talk
about "business solutions" and stuff like that but it really doesn't count
for much. Sure, that might be your bread and butter, but it might not be for
someone else. All I'm saying is, without real context, such statements are
advocacy. Even with context, the context won't be global and can't be used
to make blanket statements.
<676eej$o...@news.abest.com>
[...] the Clipper developer offers a quote of $2000 and suggests they can
deliver a test version in about a week.
Again, without any real context, this is advocacy and could be read as
insulting.
<67999v$5...@news.abest.com>
I don't CARE if you use DOS but please don't try and pretend you can write a
mouse-driven scrolling window in Clipper faster than anybody's 10 year old
brother can write one in Delphi or VB. It isn't true.
Has anyone done this? I don't remember reading any claims like this.
<6798j4$5...@news.abest.com>
Post your Clipper code for accessing mail thru SMTP, I'll whip something
together in Delphi and we can compare the number of hours spent.
Which ignores the fact that there are versions of Clipper that can handle
this sort of thing and also ignores the fact that this sort of stuff isn't
in the problem-domain of CA-Clipper (out of the box). Again, I'm not selling
Clipper, I'm just saying that asking the above doesn't make much sense when
it really isn't the sort of thing that CA-Clipper (out of the box) is good
at.
<6798j4$5...@news.abest.com>
The future is here. When you join it you'll wonder why I even bothered to
post a reply.
Sure it is, I'm nodding with this one. Obviously, there is a huge debate
about what the future is, but that's another advocacy thread in another
group. Aside from one or two people in this group I think you'd have a hard
time finding a Clipper programmer who doesn't know the way things are going
and can't see how many of the monolithic apps we used to write (include a
word processor in the application, are you MAD??) can be far better done in
an environment like Windows. You've got no argument from me on that one,
you've never had any argument from me on that one.
[NOTE: In the above, I've tried not to quote any of Tom's stuff out of
context, I've simply included the key points. Note that I've included the
Message-ID of the posts in question so people can refer back to each post.]
Like I said before Tom, I think we violently agree. Sadly you appear to have
got me confused with someone who dislikes Windows as a solution (there are
some technical reasons why I do, but that is a different matter and in no
way detracts from the fact that the ideas behind Windows make a good
solution), someone who thinks that Clipper is the only language worth
bothering with (granted, I have an affection for the language, but that is a
different matter) and someone who needs to proove that Clipper can do
everything and anything (which I've never done and I know it can't).
> >By and large, you are "preaching to the converted" anyway.
>
> It sounds great but I'm not preaching.
<g> Sure you are Tom. Nothing wrong with it either, it is one of the reasons
I read your posts. However, I wouldn't call you evangelical. :-)
(On a serious note, is this a phrase that doesn't carry over the pond too
well? You don't appear to have understood what I've said here).
> What is it about discussion that bothers you so much?
Pardon? Nothing bothers me about discussion, if it did, I'd not be
discussing this would I? Indeed, I could legitimately ask you the same
question. You appear to be ignoring what I'm saying and throwing in the odd
personal insult.
> Did you do this on the Compuserve forum when things didn't go your way?
What has Compuserve got to do with this? I had fleeting access to Compuserve
once, but other than that I've never used it. What is your point?
> What's the deal no room for legitimate alternatives in the world anymore?
<SIGH> You've really not been reading anything I've written have you. This
is *exactly* what I'm talking about, legitimate alternatives! What I'm
saying is that all legitimate alternatives be considered. Be it Delphi, VO,
VB, xBase++, Java, FlagShip, you name it.... All I added was that none of
them are alternatives if the problem at hand is a DOS problem. That is all.
Please, show me where I said there was no room for alternatives.
> >Tom, I'm very happy that you've found a tool that will allow you do solve
> >the business problems you are presented with (as it happens, it is one of
> >the tools we are considering for the next generation of our products),
> >however, the world is wider than your customer base and the problems to
> >be solved are more diverse than the specs you have on your desk right
> >now. I'm sure you can respect and understand that.
>
> Appreciate your thoughts. By the same token lots of people who use
> Clipper and frequent this group are seeking alternatives.
Yup, me included. The fact that people are looking for alternatives is
backed up by the recurring discussions about Delphi, VB and xBase++ that
crop up from time to time.
> They often prefer to get opinions from people they are familiar with,
> perhaps whose opinions they can trust and from people who likely have
> similar business problems to solve.
No argument here. Hence my suprise at some of your negative comments.
> I think you'd find it hard to convince most Clipper developers that I'm
> notfamiliar with Clipper as a solution to business development problems
> and that my use of any particular product for those problems that warrant
> Windows solutions would be inapplicable to them.
No argument here. I hope you are not suggesting that is what I'm seeking to
do.
(DejaVu) Tom, I really do suggest you go back and re-read the thread. If we
disagree on a couple of the finer points of the subject, cool, I've got no
problem with that. However, I do have a problem with been called a "jerk" by
someone who should know better and I do have a problem with having various
traits and actions attributed to me that have got nothing to do with my
views, actions or opinions.
tom leylan
ro...@sencon.com wrote:
>Sorry that you didn't notice that I was addressing Gordon Hamm. I have
>no beef with you, so chill out please.
Ross... it's got to be the medium. Seriously I can read I know you replied to
Gordon.
>Like many others, I too am considering the available paths for the
>future. Gordon has, on one or two occasions, made a passing comment
>(mild enough?) about the Delphi and Halcyon duo. I would like some real
>life info from someone who is obviously using that combination.
I've not used Halcyon (I'll go look it up) but a few hours with Delphi will
answer your basic questions. A novice can create a single .DBF file with Add,
Edit, Delete, Home, End, Skip Forward/Backward capabilities in less than 8
hours including Delphi installation and a couple of problems.
A serious Delphi developer could do it in 3 minutes. A simple report, a
listing that could be previewed in Windows might take an additional 2 minutes.
The bottom line is often... one guy will give a quote for a DOS app that they
would be willing to begin work on if somebody pays them several thousand
dollars and the other guy roughs out the application that the client is asking
about as they watch.
One guy says "when I'm finished writing it your employees shell out to DOS"
and the other guy shows how you can cut and paste data directly from Windows
into the app, create an OLE object that imports the data from MS-Word or Excel
or displays the report in HTML and using the FTP component, transmits it to
their website. And he does it (rather roughly but he does it) in under 15
minutes.
>I am also considering VB5 + Artemis and would value some insights from
>equally passionate users of that combination.
Your success with VB5 would probably be almost as great. Again, the stuff is
priced so low you can pick up a standard version for under US $100 and the
"Professional" versions are worth the little extra.
Most of the Win Development tools are migrating toward very similar IDE's and
are form-based, OOP implementations. I will guess there would be no
particularly hard work to transition the "average" Delphi app to VB or vice
versa.
>So Gordon, have you got any examples? They don't have to be rockhard
>bench tests either.
Again, I note the "Gordon" but may I suggest you formulate any kind of plan
about this. Pick something like "name, address, city, state, zip" on a form
and Add, Edit, Delete or something, a report or two and you upload a Clipper
executable and he or I could upload a Windows one.
The Win-based one will work with a mouse, will adapt to user-defined colors,
optionally resize, have fly-over hints enabled, display menu hints in a status
bar and stuff. And of course if anybody asked about timing out a user we
would just hook the built-in idle event but other than that we'll call the
DOS and Win implementations even.
>Best wishes to all, including Tom
Thanks Ross, same to you.
tom leylan
da...@hagbard.demon.co.uk wrote:
You know (I hope) that I chose the Internet out of a bag of 1000 things that
one could reasonably want to write. You want to compare "Hello World"
programs, I'll do it 60 seconds and mine will let the user select the color
of the form.
>Huh? Care about what? The only thing I care about is that the correct tool
>is used for the correct job. I've not said anything about your choice of
>tool or your choice of job.
Umm... you seem to care that Clipper is shown to be the best tool for the job
and it isn't. Clipper is no longer the best tool for the average data entry
app and that's the point that Win developers have been trying to make.
It might be the best tool for "some" job but that is only where a situation
makes it unworkable to use Windows. If it absolutely has to run on an IBM AT
then you've got the job.
>All I've commented on is some of the conclusions
>you draw because of your current choice of tool.
I'm not enamored with Delphi. I'm the person who for years posted (and you'll
find it in my book) "stop thinking of yourself as a <tool> programmer." I'm
quite capable of separating the tool from personal feelings about the tool.
How simply can I put it... I bought a copy, I tried it, it worked.
Pick your favorite editor and then I'll say "well sure you're totally slanted
toward that tool", like there isn't even a chance it is actually useful. <g>
>Yet again, I'll state, I *agree* that (CA-)Clipper isn't the language to use
>if you want to write an application that is internet aware. However, I was
>also pointing out that "all the world isn't the Internet". For example, very
>few of out customers know what the Interet is, let alone have or need a
>connection.
Again, the internet is only one example. If you could deliver a Clipper app
that could preview your LaserJet quality report on the screen I'm betting
you'd be pointing out how cool that was. I'm simply saying you can today and
you could have years ago but not using Clipper.
What is "useful" doesn't become unuseful because Clipper can't do it without
jumping through hoops.
><SIGH> Won? Won what? Defend? Defend what? I'm not defending anything. If
>you think I'm defending anything then I suggest you go back and read my post
>wth an open mind instead of assuming from the onset that anyone who posts a
>followup must be attacking the core of your business plan and disagreeing
>with the one true Leylan way.
I've never suggested that anybody follow me. I pointed out the results of a
prime number test a 60 to 1.4 differential BTW. No sooner had I posted it
than speed didn't matter.
I post facts, people draw conclusions I've never claimed my language is "the
best." I'm saying I've used Clipper (fact), I still use Clipper (fact), I've
used Delphi (fact) and Delphi is more productive, faster executing and
produces 32-bit Windows apps.
>Oddly, if you did correctly read my post, you should find that, if anything,
>we violently agree. The only difference is I'm saying that given context of
>the problem area you are coming from, (CA-)Clipper is, for the most part, an
>irrelevance. Other implementations of the Clipper language are not, or do
>you disagree with that?
And I'm trying to say that isn't the case, that the context I'm coming from is
as a Clipper developer. That in the last year I wrote a Clipper touch-screen
kiosk app, two FoxPro/DOS input apps and a Visual FoxPro data converter.
I'm saying that as a working Clipper developer I've found a tool which other
Clipper developers would do well to look into. I'm saying that if the
customer hadn't been so close minded about using an xBASE DOS tool they could
have had a more robust, easier-to-use input tool in 1/2 the time or one with
substantially more power in the same amount of time.
>> I remain dumbfounded... oh, and I've got a new jerk to add to my list.
>
>Personal attacks are beneath you Tom.
Asking me to leave the newsgroup was uncalled for. And just so we're clear,
personal attacks are the way I operate.
If you're going to try and paint a public picture of "Tom the Window's
developer has lost his ability to discern when DOS is appropriate" I'm not
going to trade politically correct witticisms... I'm going to say you're full
of it.
tom leylan
da...@hagbard.demon.co.uk wrote:
>tom leylan <tle...@abest.com> wrote:
>> You gotta be kidding Ross. I was just asked to stop posting here and all
>> I did was post the results of a simple timing test.
>I don't recall seeing anyone ask you to stop posting stuff like that. I, for
>one, was very interested in the code your posted and the results you
>got. True, Delphi is off-topic for this group, but I'm sure many of us in
>here are interested in what can be done with it from a ex-Clipper-head
>perspective, it is one of the respected "next steps".
From: Dave Pearson <da...@hagbard.demon.co.uk>
Subject: Re: Xbase++ benchmarking
Date: Wed, 17 Dec 1997 20:26:21 GMT
Organization: Hagbard's World (A Private Internet Host)
On Wed, 17 Dec 1997 19:31:10 GMT, tom leylan <tle...@abest.com> wrote:
> Look if you're sold on Clipper I'm not hear to change your mind, I'm not
> here to foist a tool on you. I'm speaking to the last few developers
> still using DOS who might be looking to write ActiveX components or
> interpret HTML or access mail servers or solve any number of current
> business problems.
Then, with all due respect Tom, you are in the wrong Usenet group. Last time
I looked comp.lang.clipper was just that, a Usenet group for programming in
the Clipper language and it's derivatives. It isn't a DOS advocacy group, it
isn't a Windows advocacy group, it isn't a Delphi advocacy group, it isn't a
OO advocacy group, it isn't a <InsertSomethingYouAreUsingNow> advocacy
group. It is a group for programming in the Clipper language. That can take
in DOS, Windows, OS/2 and Unix to name some platforms.
Frankly I'm suprised after reading your current crop of posts. I'm sure that
you, above all people, can recognise that some solutions to current business
problems still use and/or require good old DOS. Love it or hate it, some of
us still have to live with it. No matter your view, it is a fact of life.
Can I respectfully suggest that the advocacy be taken someplace else? By and
large, you are "preaching to the converted" anyway. You yourself are proof
that you don't have to be a pure DOS die-hard to hang out in this group. So
people are having some fun comparing the exec speed of the currently
available Clipper derived compilers, so what? I'd say that is on-topic and
relevent to this group, far more on topic that Delphi code and
Delphi/Windows advocacy.
Tom, I'm very happy that you've found a tool that will allow you do solve
the business problems you are presented with (as it happens, it is one of
the tools we are considering for the next generation of our products),
however, the world is wider than your customer base and the problems to be
solved are more diverse than the specs you have on your desk right now. I'm
sure you can respect and understand that.
Anyway, must go, I've got some paying DOS work to get back to.... :-)
--
Take a look in Hagbard's World: | w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ | ng2html - The NG to HTML converter.
http://www.hagbard.demon.co.uk/ | eg - Norton Guide reader for Linux.
Free software, including........| dgscan - DGROUP scanner for Clipper.
>Tom, I think very few people have a problem with long respected members of
>this group going "Delphi is the way to go when moving to Windows". I know
>that some people have a problem when long respected members of this group do
>the same but also dump on those who havn't made the move yet. Consider the
>difference.
But Delphi isn't the way to go when moving to Windows. Windows is the way to
go when developing business apps. Having used VB for less than an hour I'll
claim I can write a basic data entry app in VB in under 8 hours. It will be
mouseable, it will support all the cool things that Clipper developers post
questions about on this newsgroup.
The "dumping on" that you see is from Clipper developers who say "har, let's
see those Windoze programmers do a macro or evaluate a codeblock" like it
can't and/or there isn't a better alternative.
>Tom, I'm sure that many of the long timers in comp.lang.clipper will join me
>in saying that your posts are/were among those that we made a point of
>reading. Hence my current suprise. The fact is, you don't have to dump on
>anyone to show that your current solution is a good one (many of us know
>this anyway). There is a big difference between "I've started using X as an
>addition to my toolbox, it is neat", and "I've replaced my toolbox with X, I
>can't believe you guys are still using that old stuff, what are you all
>thinking?". Guess which way your current crop of posts are reading?
>DOS/Clipper maybe a thing of the past for your, please don't dump on those
>of us who still deal with it.
I think you've probably read the other messages by now but once again I billed
40 hours a week for the last 52 weeks for Clipper and FoxPro work. I'm a
Clipper developer for the most part.
I didn't "dump" I posted a timing test and everybody who thought speed
mattered predictably didn't think speed mattered.
Gordon Hamm
You and benchmarking... I dont know about you, but Im here to feed my
family.. (5 of them)
The world is moving to win32, if you dont learn it, you wont have the
comfortable life in the future that you are used to.. I never argue which
is better or worse, just what makes $$ fast and is in high demand.. I made a
ton of money in Clipper, (still do with older customers) but all the new
systems arent being in DOS.. VO really sucks, so Delphi was the place to
go. .. I still believe that..
The greatest thing about NT, although I know its not perfect, is that we
dont have all those dog gone memory problems anymore.. When you used to
load memory drivers and other drivers, there wasnt much left over for
clipper.. it was a constant battle for memory..
That alone is worth the move to windows NT for me..
--
Gordon Hamm
Voice Data Systems Inc.
Astoria Communications
360-686-8315
Ross McKenzie wrote in message <34987C...@sencon.com>...
>Gordon Hamm wrote:
>>
>> I agree 100%.. its time that we as Clipper heads let the "Glory Days"
go..
>> I mean , move on..
>>
>> Delphi rocks, and with Halcyon, I have the best of both worlds.. Delphi
and
>> Clipper..
>> http://www.grifsolu.com
>>
>> The apps are quick to develop, 32 bit, no runtimes, lean and mean..
>>
>> Do I sound like a preacher ?? yup.. as they say, I finally saw the
light..
>>
>> --
>> Gordon Hamm
>
>OK Gordon,
>
>Money where the mouth is <g>. Would you care to present some
>benchmarking times/tasks for your combination. I am sure there are many
>here who woyuld like to see what you and yours can do.
>
Dave Pearson
On Thu, 18 Dec 1997 14:45:14 GMT, tom leylan <tle...@abest.com> wrote:
> >Huh? Care about what? The only thing I care about is that the correct tool
> >is used for the correct job. I've not said anything about your choice of
> >tool or your choice of job.
>
> Umm... you seem to care that Clipper is shown to be the best tool for the
> job and it isn't.
Where? WHERE? Just show me where I've said anything to give you that
impression. I've said it before and I've said it again, I don't care. I only
care that Clipper is the right tool for the job if it is just that, the
right tool for the job. Which bit of this don't you understand?
> Clipper is no longer the best tool for the average data entry app and
> that's the point that Win developers have been trying to make.
While I'd question your definition of "average data entry app", I'd neither
agree or disagree with the above. I can see situations in which Windows
would be an aid and an hindrance. I choose Windows when it would be an aid,
I'd choose DOS when Windows would be a hindrance. I also believe that the
times when Windows would be a hindrance are now close to 0.
> >All I've commented on is some of the conclusions you draw because of your
> >current choice of tool.
>
> I'm not enamored with Delphi. I'm the person who for years posted (and
> you'll find it in my book) "stop thinking of yourself as a <tool>
> programmer." I'm quite capable of separating the tool from personal
> feelings about the tool.
I don't doubt it. Same here. However, like I've said before, I have an
affection for Clipper as a language, same with perl too. However, I don't
let my personal tastes, which are mainly about the "fun" aspect of computing
(I only do this because I enjoy it), get in the way of picking the right
tool for the right problem.
> Pick your favorite editor and then I'll say "well sure you're totally
> slanted toward that tool", like there isn't even a chance it is actually
> useful. <g>
Followup to comp.emacs, oops, sorry wrong thread. :-)
> >Yet again, I'll state, I *agree* that (CA-)Clipper isn't the language to
> >use if you want to write an application that is internet aware. However,
> >I was also pointing out that "all the world isn't the Internet". For
> >example, very few of out customers know what the Interet is, let alone
> >have or need a connection.
>
> Again, the internet is only one example. If you could deliver a Clipper
> app that could preview your LaserJet quality report on the screen I'm
> betting you'd be pointing out how cool that was. I'm simply saying you
> can today and you could have years ago but not using Clipper.
Agreed, I've not said otherwise. All I was adding to the above is that it
*can* be done with Clipper (the language, not the compiler from CA), either
using one of the 16bit Win add-ons (a good solution a number of years back)
or one of the up-and-coming 32bit Clipper derived solutions. Please note
that I make no value judgement there, I'm simply stating a fact. That is it,
simple, it can be done.
Obviously, the question of "should it be done" is a different thing
altogether. For the record, my current thinking is that xBase++ looks nice
and all, but I wouldn't want to bet my company on it (not that I have a
company) and if pushed right now I'd sooner go for the likes of Delphi when
making a move to Windows.
> What is "useful" doesn't become unuseful because Clipper can't do it
> without jumping through hoops.
Agreed. I've never said such a thing. I do hope you are not going to
attribute such thinking to me.
> ><SIGH> Won? Won what? Defend? Defend what? I'm not defending anything. If
> >you think I'm defending anything then I suggest you go back and read my
> >post wth an open mind instead of assuming from the onset that anyone who
> >posts a followup must be attacking the core of your business plan and
> >disagreeing with the one true Leylan way.
>
> I've never suggested that anybody follow me. I pointed out the results of
> a prime number test a 60 to 1.4 differential BTW. No sooner had I posted
> it than speed didn't matter.
You'll also note that I didn't followup your speed post, my first followup
to a post of yours in this thread was to agree with everything you said in a
different article bar one paragraph. This further leads me to believe that
you are attributing every followup to your posts to me. Again, I suggest you
go back and re-read the thread. Pay close attention to article
<slrn69doro...@hagbard.demon.co.uk>.
> >> I remain dumbfounded... oh, and I've got a new jerk to add to my list.
> >
> >Personal attacks are beneath you Tom.
>
> Asking me to leave the newsgroup was uncalled for.
I never did such a thing and you know that. I'm quite happy to admit that I
may have misread your intent when you said you were "speaking to the last
few developers still using DOS", my point, in response to that, was that
those who wanted to do Windows would be in a Windows group anyway, or would
be here doing that Windows stuff with a Clipper language derived tool, in
either case, it would be "preaching to the converted". I fail to see how you
can interpret that as "Tom, get out of comp.lang.clipper and don't come
back".
Still, if you wish to make it personal, that is your choice.
> If you're going to try and paint a public picture of "Tom the Window's
> developer has lost his ability to discern when DOS is appropriate" I'm not
> going to trade politically correct witticisms... I'm going to say you're
> full of it.
*IF* I'm going to try and paint a public picture of "Tom the Window's
developer has lost his ability to discern when DOS is appropriate" then yes,
you are well within your right to say I'm "full of it". However, that isn't
the public picture I'm painting. I'm not painting any picture, you are the
one with the brush in your hand dawbing "jerk" over the group.
Still, I can handle it, the last time I came in for a keyboard lashing off
you Tom it was when I agreed with you about OO save for my statement that
there were the odd times when OO wasn't appropriate or necessary. You'd
think I'd know better than to agree with you. :-)
JLeddon 65
Tom Leylan:
will answer your basic questions. A novice can create a single .DBF file with
Add, Edit, Delete, Home, End, Skip Forward/Backward capabilities in less than 8
hours including Delphi installation and a couple of problems.
A serious Delphi developer could do it in 3 minutes. A simple
report, a listing that could be previewed in Windows might take an additional 2
minutes.
The bottom line is often... one guy will give a quote for a DOS app
that they would be willing to begin work on if somebody pays them several
thousand dollars and the other guy roughs out the application that the client
is asking about as they watch.
One guy says "when I'm finished writing it your employees shell out
to DOS" and the other guy shows how you can cut and paste data directly from
Windows into the app, create an OLE object that imports the data from MS-Word
or Excel or displays the report in HTML and using the FTP component, transmits
it to
their website. And he does it (rather roughly but he does it) in under 15
minutes. >>>
Wow, with a powerful tool like Delphi, who needs programmers??? I'm out of a
job ! :-(
tom leylan
jled...@aol.com (JLeddon 65) wrote:
>Wow, with a powerful tool like Delphi, who needs programmers??? I'm out of a
>job ! :-(
Actually you're not. Using Delphi requires a knowledge of Object Pascal,
using VB effectively requires knowledge of BASIC, both products when accessing
a database require knowledge of database normalization, SQL, referential
integrity issues, etc.
Your quote (I note the smiley) could have been applied 10 years ago when
Clipper S'87 came out and somebody else who banked on writing things in Cobol
for the next 20 years discovered that one could create an app in far less time
using Clipper. Everybody understands how people would prefer that the world
sit still or at least revolve around their own universe of experience but it
has never worked that way.
I know it's really funny but I'm not the only person who uses Windows and the
ability to actually write applications that leverage the operating system is a
plus not a minus. I'll qualify it if you like "most people" find it a plus.
Thomas Braun
Ray,
>
> We're talking about software here, folks. It's entirely possible to do
> the same thing over and over and occasionally get different results!
>
> Ray
No, I disagree. <g>
Itæ„€ entirely impossible to do _exactly_the_same_ thing a second time
(let alone more than twice).
Thats the true reason why you get those different results from
time to time.
You think you do the same but sometimes the degree of complexity of the
context in which you are doing it is so high that
you canæ„’ see the difference between the first and second one.
Thomas
The Graphical Gnome
In article <67999v$5...@news.abest.com>, tle...@abest.com (tom leylan) wrote:
>r...@ktibv.nl (The Graphical Gnome) wrote:
>>tle...@abest.com (tom leylan) wrote:
>
>
>>>and among them is it's a native code 32-bit compiler.
>
>>I strongly doubt that. I work in Both Clipper and Delphi 2.0/3.0.
>
>Well okay. I suggest it will, you suggest it won't.
>
>>If I try to search for a string in a 70.000 records database. I'm pretty sure
>>that Clipper will win.
>
>Actually you probably mean if you open a 70,000 record .DBF file.
>You might search for a string I haven't found too many companies who
>operate on the "searching for a string" business model.
You made the claim ANY test. For my application, it's very important to be
able to search fast in a large database.
>
>What I'm trying to say is, let's say you can find an arbitrary string 10 times
>faster than I can, how much closer does that make them to finishing a business
>application?
Again, a benchmark is just a small part of an application. And You said ANY
test.
>
>>An other reason for using Clipper is that it is still fast on a Laptop 386
>>instead of a Desktop P166.
>
>You can use S'87 on an 8086 with a 5 MB hard drive. Probably should have
>reconsidered the upgrade to 5.0.
I'm running 5.2, and yes that will still run on a AT. I do not know about a
XT.
And you can run Delphi on a 386 and not on a XT.
>
>>Don't compare to much. Try to get the BEST tools, not the fastest.
>
>Look if you're sold on Clipper I'm not hear to change your mind,
I'm not sold on Clipper. I earn my money with Delphi and do a lot of
programming in Delphi. The point I'm trying to make is that in a lot of things
Clipper is faster and better than a windows application like Delphi.
>
>And BTW, ignore the benchmark... unless Clipper won then of course it proves
>what we all know.
BTW did you see what came out as the BEST development tool of 1997: VB5.
So much for opjective data about what tool to use.
Ron Cherry
Never mind, I think I get it. When x % aPrime[ y ] == 0, it's not
prime.
A Prime number divided by <whatever> would always have a remainder.
And the reason my test in Clipper seemed to yield 501 primes is because
of
the floating point math error, so that during the test 18 / 6 =
3.000000003,
or something like that.
By the way, this thread has gotten so confusing I can't follow it.
I'm going back to work. [hint]
Thanks,
Ron Cherry
> Phil Barnett wrote:
> >
> > This benchmark is a function which determines the prime numbers under
> > 1000. The sieve function was repeated 1000 times.
Dave Pearson
On Thu, 18 Dec 1997 14:59:03 GMT, tom leylan <tle...@abest.com> wrote:
> >I don't recall seeing anyone ask you to stop posting stuff like that. I,
> >for one, was very interested in the code your posted and the results you
> >got. True, Delphi is off-topic for this group, but I'm sure many of us in
> >here are interested in what can be done with it from a ex-Clipper-head
> >perspective, it is one of the respected "next steps".
>
> [SNIP my messages, included my Tom]
Not in there I didn't. Please re-post it and annotate the part where I said
you sould not post a time test done for Delphi. Someone may have said you
shouldn't have done it, if they did it didn't make it to the news server on
hagbard. I can tell you for certain that I didn't post any such message.
> >Tom, I think very few people have a problem with long respected members of
> >this group going "Delphi is the way to go when moving to Windows". I know
> >that some people have a problem when long respected members of this group do
> >the same but also dump on those who havn't made the move yet. Consider the
> >difference.
>
> But Delphi isn't the way to go when moving to Windows.
Ok, yeah, I was too specific there.
> Windows is the way to go when developing business apps.
You think? While, for the most, I'll agree with you, I've also got an eye on
the likes of Java style technology, not that I think that it will "win thru"
given the momentum of Microsoft. Anyway, yeah, for most business apps,
Windows is the most widely supported solution and the most sensible area to
be in, no argument here. Just for the record, I personally am suprised that
so many Windows developers seem to only want to use one tool when the whole
idea is to use the right tool for the right problem (sub-system, call it
what you will).
> The "dumping on" that you see is from Clipper developers who say "har,
> let's see those Windoze programmers do a macro or evaluate a codeblock"
> like it can't and/or there isn't a better alternative.
Yeah, I do cringe about this too to some degree. That said, if something
comes of the likes of xBase++, this really isn't a problem. If people want
to keep their code blocks, they can keep them. And, this, to a large degree,
is the point I've been getting at. Windows is the solution for a large
number of problems, you've said so yourself. The language/tool is
secondary. So, if xBase++ matures into a solid platform, Clipper is still an
option, just another tool for the Windows developer and a known quantity for
those who like their Clipper code. Again, this isn't "selling Clipper", it
isn't any kind of value judgement, it is simply a statement of fact.
> I didn't "dump" I posted a timing test and everybody who thought speed
> mattered predictably didn't think speed mattered.
Hmm, well, you can count me out of that. I didn't make any kind of value
judgement about the speed tests either way. Come to think of it, I don't
really recall anyone doing so, a couple of people did follow up with ideas
about "better" tests but I don't recall any "Clipper lost so it doesn't
count" kind of messages. Indeed, the speed tests, AFAICT, were posted more
out of curiosity as to how "fast" xBase++ is compared to good old
CA-Clipper. Again, I don't recall any value judgements been made.
Anne Krijger
tle...@abest.com (tom leylan) (tom leylan) wrote:>
Hi Tom,
I'm going to jump in here now, although I promissed myself to keep out of this
thread :) Your last remark got my attention though...
As far as the dumping/asking to leave is concerned; depending on your POV some
of your posts can indeed be read as one of those 'why are you idiots still using
CLipper, product X is much better.' posts that we've seen many of before.
Those we can do without.
You may not have intended them that way, as I understand you agitated more
against the 'Clipper is the best tool in the entire world' claims.
That we can use :)
Personally I don't hold high regard for benchmarks when it comes to
comparing tools that run in entirely different contexts/enviroments. But that's
just MO.
> But Delphi isn't the way to go when moving to Windows. Windows is the way to
> go when developing business apps.
And even that can be disputed, depending on what platform the client is using...
This was the remark that got my attention:
> I think you've probably read the other messages by now but once again I billed
> 40 hours a week for the last 52 weeks for Clipper and FoxPro work. I'm a
> Clipper developer for the most part.
I've been talking to a friend who works for a data-processing company.
They used FoxPro to process the data in the Dbf's because FoxPro is/was? one of
the fastest tools around and speed is their main problem.
They are moving towards Visual FoxPro now and I was wondering how Visual FoxPro
relates to Delphi for example. I've never done any work with FoxPro myself, nor
any serious work with Delphi, so I can't tell from own experience how the two
would relate, specially where speed is concerned.
BTW, have you ever looked at XBase++ ?
I would be interested in knowing how that relates to Delphi too...
> I didn't "dump" I posted a timing test and everybody who thought speed
> mattered predictably didn't think speed mattered.
Speed matters, but often is only part of the picture.
I for example am willing to lose some speed if my app becomes easier to
maintain.
Anne.
Anne Krijger
"Gordon Hamm" <v...@astoria.com> (Gordon Hamm) wrote:>
> You and benchmarking... I dont know about you, but Im here to feed my
> family.. (5 of them)
5 families ?! :)
> The world is moving to win32, if you dont learn it, you wont have the
> comfortable life in the future that you are used to..
FWIW, I read today that all the Fortune 100 companies use DB2 :)
> systems arent being in DOS.. VO really sucks, so Delphi was the place to
> go. .. I still believe that..
Ehhh, VO used to suck. From what I hear it's a decent tool these days.
> The greatest thing about NT, although I know its not perfect, is that we
> dont have all those dog gone memory problems anymore.. When you used to
Sorry ?
It's memory requirements are one of the worst things of NT.
> load memory drivers and other drivers, there wasnt much left over for
> clipper.. it was a constant battle for memory..
And then we moved to PM apps and our problems were solved :)
> That alone is worth the move to windows NT for me..
Sorry, but I can't agree with you there.
There are numerous reasons to start development for the Win32 enviroment, but
just to do so to get rid of the 640K memory limit seems a bit 'overdone' to me
:)
Cobol rules ! :)
Anne.
Phil Barnett
On Thu, 18 Dec 1997 14:59:03 GMT, tle...@abest.com (tom leylan)
wrote:
>I didn't "dump" I posted a timing test and everybody who thought speed
>mattered predictably didn't think speed mattered.
I thought it was very good comparison and hit the mark dead on. Your
generally condescending attitude was not very well received, but I can
get past that. Probably you didn't intend it that way, but that's the
way it came off. No biggy.
The entire idea about my original post was to compare the tools I had
at hand and use the most, particularly the new Xbase++ compiler. I
don't consider Delphi to be an Xbase languge, so I never ported the
code over to test it. (not that there was anything xBase'ish about the
test) In general, I like Delphi.
I didn't port it to VdB5.5 or VB5 because I really don't care.
I didn't port it to C or C++ because it would obviously blow the doors
off of any Xbase implementation.
I certainly didn't port it to .ASM for the same reason. I bet an .ASM
version of the sieve would only flash on the screen.
But, I did find the other ports and comparisons interesting and
informational. I even requested the source and executable for future
comparisons. I'd like the source and executable for your test. I liked
what you did.
These simple tests give us a method by which we can measure our tool.
;)
I still like Clipper the best, but I'm getting to like Xbase++ a lot.
You know why?
It's Clipper. And a whole lot more.
Someone finally delivered on a non-total-rewrite upgrade path for
Clipper code into a native 32 bit executable that doesn't have all the
bad habits of it's 16 bit predecessors, like 12 character file names,
processor stuck at 100%, mouse, etc. In these respects, it's the trip
and fall point of Clipper development. Clipper really sucks in these
areas. Workaround and hack as we may, there are no great answers.
Please, Tom. Bear with us. Most of us are making a living supporting
legacy apps that won't be rewritten in a more modern language for
years. Why? Because they already solve the basic problems of the
business at hand. The same reason why new development is better off in
a new language. I don't think that you'll find that many of us
actually seriously propose _new_ Clipper solutions unless it is a
minor adjunct to an existing system.
I sure don't.
---
Phil Barnett mailto:philb@iag~net <-anti spam replace ~ with .
WWW http://www.iag.net/~philb/
FTP Site ftp://ftp.iag.net/pub/clipper
Seems to me that the same situation holds when forecasting
the aggregate effects of several billion embedded chips,
PCs, mainframes, and interlocking components of the
socio-economic inframumblestructure all hiccuping at
more-or-less the same time.
Ed Yourdon commenting on the inability to predict
the future regarding Y2K problems.
David Barrett
On Thu, 18 Dec 1997 03:01:53 GMT, tle...@abest.com (tom leylan)
wrote:
>Anybody who honestly posts anything positive about Delphi or VB or any
>non-Clipper related product is going to face a barrage of crap. We've all
>seen it a hundred times with VO... smartest guy in the world using Clipper
>becomes the dumbest ass on Earth the moment he didn't choose VO.
>
>Smartest VO developer on the planet became the lowliest sucker in the universe
>the moment he switched from VO to something else.
>
>It's religion and religion is all about faith not facts.
>
>I gotta go.. you guys depress me too much.
>
>Tom
Boy! What goes around, comes around, huh Tom? I remember well when
you were one of the high priests of the Clipper religion -- heaping
scorn on anyone who was not a true believer. Well, how does it feel
to be on the other side, Tom?
David Barrett
V.Kazimirchik
tom leylan wrote:
[wire cutters applied]
> I remain dumbfounded... oh, and I've got a new jerk to add to my list.
>
Please also post a Clipper/Delphi comparison test based on your
'jerks list' search query...
--
Sorry, couldn't resist. Vladimir.
My email is kzm11 at geocities dot com
or look at http://www.geocities.com/SiliconValley/Pines/7762/index.html
Sean Webb
On 12/18/97 1:13AM, in message <679ma4$r...@news.abest.com>, tom leylan
<tle...@abest.com> wrote:
> da...@hagbard.demon.co.uk wrote:
>
> I remain dumbfounded... oh, and I've got a new jerk to add to my list.
>
Thats a highly unfair kind of statemnt to post vs Dave !!
Ever thought of adding your own name to your list , or is it already sitting there
on top in large letters ??
Sometimes i wonder if you had a hand in nantuckets demise.
Bad attitude and over arrogance can cause problems among your peers and
demote both productivity and creativity.
--
Sean Webb , Spyder Computing
Security & Risk Management Systems (Shopping Malls, Waterfronts, Guarding
Companies, CBD's ) . Fire & Rescue database applications
Marina Booking Systems , POS developments.
Personal Home page:- http://users.iafrica.com/s/sp/spwebb
Sean Webb
On 12/17/97 9:18PM, in message <6798j4$5...@news.abest.com>, tom leylan
<tle...@abest.com> wrote:
>access the internet... I am however willing to be proven wrong. Post your
> Clipper code for accessing mail thru SMTP, I'll whip something together in
> Delphi and we can compare the number of hours spent.
>
Too easy :))
SendMail("ct-smtp.iafrica.com",cFrom,cReply_to,aCto,cSubject,cMsg,;
lIs_html,cBase,acCC,cAttach)
Time taken 15 seconds.
How long in Delphi ??
William McDonald posted a SMTP class for clip-4-win a while ago on the
clip-4-win mailing list.
Takes one line to call.
One line , i win :)))
And yes i know about the delphi inet components :)))))
If you want , i can send you an email from one of my apps and you can check the
mailer header when you get it if you don't believe it.
>
> Again... I like you Sean but nobody really cares about .DBF manipulation. Ask
> CA if they care about .DBF manipulation, ask any large company.
>
Well, i have clients running Gb databases quite happily , i also design off the
shelf s/w. People in this part of the world aren't keen on spending a few bucks
on a s/w package then going out and buying the license for an SQL server at
10 x the price of my s/w.
> >3) Different results again if you bypassed the BDE and used halcyon with
> > delphi for manipulating DBFS.
>
> Different results... okay, and your point would be?
>
Again different results , and possibly faster access time than SQL.
> I'm not recommending Delphi I'm stating a fact, it is
> generally more powerful, at least as reliable, it is object-oriented, it is a
> native code compiler, the tools that are included are great, it generates
> Win'95 and NT applications. Are you suggesting I've lied anywhere?
>
No , just a bit over zealous. BTW using clip4win i have SMTP ,FTP , OLE,ODBc
VBX etc support , full winapi , but still 16 bit.
But i hear that 4win might be going 32 bit as well.
> I'll let you in on a secret Sean... One day you will pick up a Window-hosted
> language and when doofuses explain how much more productive they are
> using
> their DOS compiler and how you can't do anything they can do you'll gaze into
> the sky and just wonder where these people come from.
>
I wonder what all these books sitting in front of me are called ....
Visual Basic , Access unleashed , Delphi developer guide , Charles Petzold's
programming windows , Btrieve for windows NT/95 , ODBC interface reference
manual , to name a few.
Nope , nothing there about programming in windows.
Well Tom , i'll let you in on a couple of little secrets.
1) I got my first copy of Delphi when version 1.0 came out.
I also have the 32 bit btrieve drivers for Delphi , and also there is the btrieve
SQL for delphi , which can be used for simultaeneous SQL and betrieve
access.
2) I just converted a DOS clipper app to windows using clip4win
Size of the APP 2.6mb of source code. (+/- 100,000 lines of code)
Project started 1 august 1997.
Delivered 15 December 1997.
The client was offered both the 4win conversion and the Delphi conversion
Difference being that that the 4win version was 1/3 the price of Delphi.
Now are you going to try and say that this could have been done faster in
Delphi ??
3) Straight delphi on its own sucks for database development , without either
a) Buying lots of components
or
b) Writting lots of components your self.
4) Delphi quick reports isn't worth the space its wastes on the HDD , and its
name is a total misnomer.
Report smith , even more so
> > You can only compare like with like.
>
> No you can't. A business can compare ground transportation with air
> transportation they can compare 16-bit DOS implementations against 32-bit
> Windows implementations. They want a job done and if they want to preview
>
>reports with imbedded graphics before they print then you can bark all you
> want about the unfair comparison or reference ClipPreviewReport-O-Matic
> from
Thats funny , but the 2.6mb app that i cited above has 154 reports in it , and
funnily enough each one has a print preview just like the one in ms word
displaying text ,graphics 24 bit colour etc. And it written in clipper , using
4win and the topclass OO engine supplied with.
You may have worked for nantucket , but you are behind the times when it comes
to knowing what the capabilities are of the tools that come with clipper.
Also , i know for a fact that you can do the same with 5win.
> The future is here. When you join it you'll wonder why I even bothered to
> post a reply.
>
>
Well i happen to be spending +/- 280 hrs / month these days writting windows s/w
so maybe , just maybe i have a tiny bit of a clue as to what is going on ??
Craig Jarvis
Dave Pearson wrote:
> Function SendMail( cFrom, cTo, cSubject, cSmartHost, cText )
> Local cTmpFile := UniqueName()
>
> memowrit( cTmpFile, cText )
>
> swpruncmd( "sendmail -f " + cFrom + " -s " + '"' + cSubject + '"' +;
> " -F " + cTmpFile + " -t " + cTo + " -r " + cSmartHost )
>
> ferase( cTmpFile )
>
> Return( NIL )
Hi Dave
I know this is off the topic of the thread, but I am interested in this
solution. Where did the "sendmail" come from? I would find it quite
useful to be able to send Email from a Clipper app.
I hope I am not attacked - I tried not to insult anyone!
Regards
Craig Jarvis
Cape Town, South Africa
Dave Pearson
On Fri, 19 Dec 97 12:01:50 GMT, Sean Webb <spw...@iafrica.com> wrote:
> You may have worked for nantucket , but you are behind the times when it
> comes to knowing what the capabilities are of the tools that come with
> clipper.
[Jumping in]
<NITPICK>
Has Clip4Win ever "come with" CA-Clipper?
</NITPICK>
tom leylan
an...@hacom.nl wrote:
Gosh, not you too...
Are we playing silly arguments this week?
>FWIW, I read today that all the Fortune 100 companies use DB2 :)
>Sorry ?
>It's memory requirements are one of the worst things of NT.
>> load memory drivers and other drivers, there wasnt much left over for
>> clipper.. it was a constant battle for memory..
What are the memory requirements to run DB2 and how do those machines handle
Clipper?
>Ehhh, VO used to suck. From what I hear it's a decent tool these days.
You're reading the wrong propaganda.
tom leylan
>Boy! What goes around, comes around, huh Tom? I remember well when
>you were one of the high priests of the Clipper religion -- heaping
>scorn on anyone who was not a true believer. Well, how does it feel
>to be on the other side, Tom?
Sure Dave... you recall any point in time where I said that Window sucks or
32-bit operating systems or lots of RAM or greater speeds was a detriment?
Of course not. What you recall is my arguing that Clipper was a superior tool
to FoxPro and dBASE. That the Clipper language with the introduction of
lexical scoping and minor improvements like increment and decrement operators
along with SET() functions that let you retrieve the current state was better
than a language that didn't have those things.
I've never believed and don't recall ever posting that Clipper was better than
C, I know for a fact I've bemoaned the horrible .DBF structured DBMS, I've
never suggested SQL was a waste of time and if you'd care to review anything
I've ever written on Clipper you'll notice I routinely suggested that people
avoid certain constructs with the warning "while this will work in Clipper it
will not work in any other language."
Does anybody read these messages or do they just press reply and start typing?
Dave Pearson
On Fri, 19 Dec 1997 15:22:26 +0200, Craig Jarvis <craig....@datamax.co.za> wrote:
> > swpruncmd( "sendmail -f " + cFrom + " -s " + '"' + cSubject + '"' +;
> > " -F " + cTmpFile + " -t " + cTo + " -r " + cSmartHost )
>
> I know this is off the topic of the thread, but I am interested in this
> solution. Where did the "sendmail" come from? I would find it quite
> useful to be able to send Email from a Clipper app.
Ok, first off, I would really like to reiterate that the above was
tounge-in-cheek and I'd not recommend it as a solution. There are a hell of
a lot of flaws in doing something like the above. However, that said...
SENDMAIL.EXE is a (Unix)SendMail-a-like aimed at NT and 95 (so, obviously,
your Clipper app has to be running on a NT/95 machine). There is more than
one work alike that has the /usr/bin/sendmail style interface for submitting
mail to the local mail spool (WSENDMAIL.EXE is another one that springs to
mind) so keep your eye out.
The reason for such an utility is that many people write cgi scripts for web
servers (in perl for example) with the idea of running them on more than one
platform. Now, if your script wants to send mail, the usual method is to
pass off the mail to /usr/bin/sendmail and let it do all the hard
work. Hence the clone, the scripts can still work when run on a WinTel box.
Please note, for the sendmail.exe I was using to work you need a SMTP host
to hand (hagbard is running Linux and so does the job, sendmail.exe was
running on Eris, my 95 box). If your office is setup to run a SMTP/POP3
style mail system then you probably do have a SMTP host and so it will work.
(Double checks something at the back of his mind)
Ooo, hang on, it also supports MAPI and XMAPI so you can probably ignore the
above note.
Now, don't ask me where I got it from, I really can't remember. The help
says:
----------------------------------------------------------------------------
Welcome to sendmail/NT, a mailer stub for Windows/NT and Windows/95.
(c) Nigel R. Ellis <nig...@microsoft.com> 1994 - 1995.
This version built on Jun 5 1995 at 14:56:11
Usage: SENDMAIL.EXE [-h localhostname] [-r smtphost] [-m transport]
[-U MAPIUser] [-P MAPIPasswd]
-t {ToList} -f From [-s Subject] -F File
{ToList} is a space, comma or semi-colon delimited list of recipients
Valid transports are XMAPI (allow edit before send), MAPI and SMTP
Default transport is SMTP
----------------------------------------------------------------------------
Hope this helps.
tom leylan
r...@ktibv.nl (The Graphical Gnome) wrote:
>You made the claim ANY test. For my application, it's very important to be
>able to search fast in a large database.
If it is "very" important then you might want to test your theory against
other products. From what you've posted it appears to be important that you
get whatever speed, whatever version of Clipper you happen to be using.
>BTW did you see what came out as the BEST development tool of 1997: VB5.
>So much for opjective data about what tool to use.
So to wrap up if you vote for Clipper then it is the best and if other people
vote for VB5 then it's a joke.
I remain puzzled.
tom leylan
nu...@iag.net wrote:
>I thought it was very good comparison and hit the mark dead on. Your
>generally condescending attitude was not very well received, but I can
>get past that. Probably you didn't intend it that way, but that's the
>way it came off. No biggy.
I wish it could come off different but somebody accuses me of calling Clipper
developers "stupid" for not using Delphi and that's not what I think and not
what I did.
I accuse them of being small-minded and Clipper-centric. I wrote a short
opinion piece for DataBased Advisor called "dBASE-O-Centric" many years ago
suggesting that xBASE developers should not believe that xBASE is the center
of the universe.
>I didn't port it to VdB5.5 or VB5 because I really don't care.
I'm not blaming you for not porting it to every conceivable language. I was
surprised that when results showing 1.4 seconds was posted, nobody wrote,
"wow" or "wow, I wish Clipper could do that" or anything positive and reacted
predictably with "get out you Delphi-head", "yeah or VB <yuck>" and other
stuff which I label "crap."
>I didn't port it to C or C++ because it would obviously blow the doors
>off of any Xbase implementation.
>I certainly didn't port it to .ASM for the same reason. I bet an .ASM
>version of the sieve would only flash on the screen.
Pardon me but I see these as obfuscation tactics. Whenever somebody is trying
to divert attention they mention "Linux drivers" or assembler and then
somebody says they use a hex editor to program in.
I posted the results of a high-level language that is commonly available,
reasonably priced, used by many, that isn't particular difficult to learn and
that it turns out many Clipper programmers have transitioned to. VB5 is an
alternative as would be Visual dBASE, note I never mentioned Ada or Lisp or
that everybody purchase a used Next machine.
Note I didn't suggest they even purchase Delphi except to one person who
asked to have some other benchmarks posted.
>Please, Tom. Bear with us. Most of us are making a living supporting
>legacy apps that won't be rewritten in a more modern language for
>years. Why? Because they already solve the basic problems of the
>business at hand. The same reason why new development is better off in
>a new language. I don't think that you'll find that many of us
>actually seriously propose _new_ Clipper solutions unless it is a
>minor adjunct to an existing system.
Phil. I'm one of them. I just accepted another contract maintaining legacy
Clipper code. I spent the last year maintaining legacy Clipper and FoxPro
code. Why? Because despite the fact that I could have rewritten it for less
money than it was costing them to maintain the faulty code (this was on the
last project) they didn't believe it.
They _didn't_ solve the business problem at hand but clearly somebody who
either doesn't know the truth and doesn't want to know the truth thought it
was in their best interest to make sure that everybody else thinks nothing is
going to be better than the collection of stuff they have at the moment.
I really just wanted to post the numeric results all this chatter is of no
interest to me but I appreciate your reply.
Tom
Dave Pearson
On Fri, 19 Dec 1997 14:37:26 GMT, tom leylan <tle...@abest.com> wrote:
> Pardon me but I see these as obfuscation tactics. Whenever somebody is
> trying to divert attention they mention "Linux drivers" or assembler and
> then somebody says they use a hex editor to program in.
The "Linux drivers" thing was not a tactic in obfuscation or diversion and
you know that. What I was saying was considering CA-Clipper (out of the box)
as a tool to solve problems in a domain where only Windows oriented
development tools make sense it like considering Windows development tools
as tools for developing Linux drivers (that is, with a lot of mucking
around, it *could* be done, but you've be mad to try). Perhaps I'm missing
something, but I fail to see how that is obfuscation or diversion.
tom leylan
da...@hagbard.demon.co.uk wrote:
>This is just plain wrong. If you are talking about what can be done with the
>tool "out of the box", then yeah, I'd pretty much nod in agreement as you
>say the above, however, if you are talking about doing the above with the
>correct tools for each language (correct tools for Pascal, correct tools for
>Clipper) then I'd have to disagree. Where I work, we've got the framework
>for doing the above in a Clipper app in not too many lines of code. Perhaps
>slightly more than the respective Delphi app, perhaps less, but it wouldn't
>be a 2K one week+ solution.
But Dave <g> you don't get all the Clipper work filtered thru "where you work"
do you? Rather than just nitpick I'll ask if your routine supports long file
names? If so, I'll ask how many other Clipper developers do you imagine have
such a module?
Of course I'm generalizing, if we all spoke in absolute terms we couldn't
possibly speak since somebody would always be able to say, "I wrote <blah> in
interpreted <bleep> on a <blech> and it ran twice as fast as <bling> on
<bloop>." Simply substitute a very good blah programmer and powerful blech
and a poor bling-head using an old bloop.
Let me try and narrow what seems to be yet another point of
miscommunication... in Delphi you pick up a pre-built, pre-tested component
for choosing files and you drop it on a form. It is controllable and
modifiable but it does most of what people want done right off the bat AND
everybody who has Delphi has access to it they don't have to ask Dave to send
his code along.
Using these types of common dialogs people who wrote apps in Win 3.1 noticed
that they immediately had the Win'95 look and feel without any additional
work. This is traditionally considered a good thing but surely we can get a
comment from Joe Bob Tubbs who will explain how I've never been to Tennessee
where all his clients there hate Win '95, think Clipper is the greatest and
that I have no idea what "real" programmers do for a living.
>In terms of getting the correct *technical* solution (that it, it works well, it is
>secure, it is fast, etc) then benchmarking things like database access are
>important for a specific solution.
DBF files are both insecure and suffer horribly from the lack of referential
integrity. A wrong answer fast is no answer at all.
>But, like I said, the question then is "what database"? What do you
>benchmark? Are you going to benchmark against some local access database?
>Some form of database server? What sort of server? What sort of hardware?
>What sort of connection? What sort of network card? What sort of.....
You're reiterating standard benchmarking questions. Most have been answered
in reasonable terms by people/companies that develop benchmarks. You might as
well ask "what language" and question whether lexical scoping or
object-orientation or virtual memory, or multi-splay arrays or any other
single thing is "important."
Is it important if Clipper has a SET function which returns current settings,
surely somebody who uses an old version of dBASE can say he was quite able to
write apps without it. Does that negate the relative importance of a SET
function? Of course not unless you have some vested interest in making
certain your tool wins the contest.
Lexical scoping is a good thing not because Clipper has it but because it has
been demonstrated to be a good thing. And to answer your specific question,
nobody cares what sort of network card "exactly" the nature of benchmarks only
dictates that identical equipment be used in each test whenever possible. If
you're testing PC implementations vs Mac implementations this can't be done so
you point that out in the test results.
>(For general consumption, not in direct response to Tom) Benchmarks are fun,
>but that is it. They serve no other purpose *unless you do them yourself*
>and *in the context of the solution you are attempting to provide*. And,
>even then, you have to ask the right questions and draw the correct
>conclusions. Anyone why thinks this thread is anything serious is missing
>the point and missing it in a big way. To see how misleading all of this is
>look at the Fibonacci benchmark I posted the other day. Depending on which
>way you look at it, Clipper blows xBase++ out of the water. To think in
>those terms would be to mislead yourself.
Well I disagree. Benchmarking isn't something a few people in a newsgroup
decide upon. If you think that interpreted BASIC is going to surpass Clipper
in a fundamental test of execution speed if you just look at it a special way
I think you'll be disappointed. And I will state categorically that if Delphi
returned 60 seconds and Clipper returned 1.4 nobody would post "benchmarks
don't have relevance."
>This is why I think Tom was partly wrong in his post (at least in the quoted
>paragraph). He correctly showed that at the end of the day benchmarks don't
>count for much "in the real world", I'm just suprised that he attempted to
>conclude his post with another bogus benchmark that appears to be based on
>suspect data. :-)
You're still hoping that Clipper will outperform Delphi and it won't. I'm a
little slow so if you could explain the difference between "bogus" benchmarks
and the kind of benchmarks you say don't mean anything we could compare the
languages again.
Dave... why are you so dead set on pursuing this "Clipper is God" thing? Pick
your fastest Clipper routine and I'll see what I can do to stomp it. I don't
want it to be bogus so you pick it.
Sean Webb
On 12/19/97 3:22PM, in message <349A7512...@datamax.co.za>,
Craig Jarvis <craig....@datamax.co.za> wrote:
> Hi Dave
>
> I know this is off the topic of the thread, but I am interested in this
> solution. Where did the "sendmail" come from? I would find it quite
> useful to be able to send Email from a Clipper app.
>
Craig. If you get a copy of pegasus mail , then the windows version has
command line calling , as i suspect the dos version might.
In which case daves example would work pretty much ok.
tom leylan
da...@hagbard.demon.co.uk wrote:
>On Fri, 19 Dec 97 12:01:50 GMT, Sean Webb <spw...@iafrica.com> wrote:
>
>> comes to knowing what the capabilities are of the tools that come with
>> clipper.
>
>
><NITPICK>
>Has Clip4Win ever "come with" CA-Clipper?
></NITPICK>
Okay you're off my list <g>
You make me laugh Dave...
Take care,
tom
tom leylan
"Phil McGuinness" <hey...@sherlock.com.au> wrote:
>VO is a very decent and reliable development tool these days. With all the
>'speed' hype in this thread it really should be benchmarked as well.
I assume you have VO 2.n and could compile the Clipper code provided with no
or little modification right?
>My customers have been
>condition by Microsoft that Windows apps run slower, an are prone to
>'break'. I am glad to say when you deploy a VO app it is very stable.
Most DOS apps I've seen run faster with the version of DOS supplied with
Win'95. And it's not like I don't believe you but in the same message you
said your VO apps run faster than Clipper and then that Windows apps run
slower.
Delphi completed the prime number routine in 1.4 seconds... just guessing what
sort of increase do you think we would get if there was a Delphi/DOS? And the
biggest question is how do you explain that Clipper, xBASE++ and Force were
slower given their DOS hosting and Delphi's Window's hosting?
I'm guessing that "Windows apps run slower" might not be true but then I'm
basing that on the results of timing tests so goodness knows what I might be
missing.
Gordon Hamm
>Sorry, but I can't agree with you there.
>There are numerous reasons to start development for the Win32 enviroment,
but
>just to do so to get rid of the 640K memory limit seems a bit 'overdone' to
me
>:)
You're right, there are at least 500 reasons to move to the 32 bit world.
There really are !
Why do you fight the future so much ?? I'm tring to think of just one thing
that I miss about the dos world, just one..
Oh, I know, you are going to say something about running on a 386... Why the
heck would you want to continue to run on a 386 when you can buy a good
pentium 166 for less than a grand?? I dont get it.. Are you poor ??
I find this argument funny.. It's not really an argument.. Because you
are so wrong about everything you are saying.. I would love to see you state
these things in ANY technology/ Computer magazine, they would laugh you to
scorn.. I think you might be alot like I was a few years back, when I just
had plain old fear of learning something new.. Then I got some courage, and
jumped in, Im glad I did..
I think that is why so many of you use things like Fivewin and Clip4win.
You think you are doing well by leveraging on your clipper knowledge, but in
reality, by the time get done hard coding a windows app (16 bit I might
add), you could have learned an elegant language like C++ or Delphi.
You need that graphical interface to do windows..
Tom is a little rough around the edges, but he right on..
I too am a CLipper guy from way back. It was good to me.. I made a ton of
money on our third party lib "CLipVoice". But really guys, let it go..
sure, maintain your legacy code..
But dont continue down that lonely Clipper road. I mean, you are not doing
your customers any service by recomending Clipper for a New app. I still
believe in using DBFS and not convinced that everything needs to be "SQL" .
Listen to your Dad, GET OUT WHILE YOU STILL CAN !! <Big G>
Get your copy of Delphi or MS C++ today !!
--
Gordon Hamm
Voice Data Systems Inc.
Astoria Communications
360-686-8315
Phil McGuinness
[reply]
VO is a very decent and reliable development tool these days. With all the
'speed' hype
in this thread it really should be benchmarked as well. My real live tests
in real live situations have VO 2.0a1 running about 30-40% Faster than
Clipper 5.2e. My customers have been
condition by Microsoft that Windows apps run slower, an are prone to
'break'. I am glad
to say when you deploy a VO app it is very stable.
The right language is the one you can understand, master and deploy with the
least amount
of pain to the developer and the end user!!
Phil - Sherlock Software - Australia
[snip]
tom leylan wrote in message <67dvr5$6...@news.abest.com>...
>an...@hacom.nl wrote:
>
>>Are we playing silly arguments this week?
>
Anne Krijger
"Gordon Hamm" <v...@astoria.com> (Gordon Hamm) wrote:>
> You and benchmarking... I dont know about you, but Im here to feed my
> family.. (5 of them)
5 families ?! :)
> The world is moving to win32, if you dont learn it, you wont have the
> comfortable life in the future that you are used to..
FWIW, I read today that all the Fortune 100 companies use DB2 :)
> systems arent being in DOS.. VO really sucks, so Delphi was the place to
> go. .. I still believe that..
Ehhh, VO used to suck. From what I hear it's a decent tool these days.
> The greatest thing about NT, although I know its not perfect, is that we
> dont have all those dog gone memory problems anymore.. When you used to
Sorry ?
It's memory requirements are one of the worst things of NT.
> load memory drivers and other drivers, there wasnt much left over for
> clipper.. it was a constant battle for memory..
And then we moved to PM apps and our problems were solved :)
> That alone is worth the move to windows NT for me..
Sorry, but I can't agree with you there.
There are numerous reasons to start development for the Win32 enviroment, but
just to do so to get rid of the 640K memory limit seems a bit 'overdone' to me
:)
Cobol rules ! :)
Anne.
Anne Krijger
tle...@abest.com (tom leylan) (tom leylan) wrote:>
Ehhh TOm,
From where I'm sitting it looks like you and Dave violently agree, both on what
Clipper is/isn't can/can't should be used for/shouldn't be used for as well as
what can be done with a Win development tool. It's sort of bewildering to see
you guys do it so intensively though, that's usually only the case when people
disagree...
> personal attacks are the way I operate.
But you don't mean that in a bad way, right ? :)
Anne.
Anne Krijger
Sure tom !
Whenever there is an argument, silly or not, I'm there :)
> >FWIW, I read today that all the Fortune 100 companies use DB2 :)
> >Sorry ?
> >It's memory requirements are one of the worst things of NT.
> >> load memory drivers and other drivers, there wasnt much left over for
> >> clipper.. it was a constant battle for memory..
> What are the memory requirements to run DB2 and how do those machines handle
> Clipper?
Depends on the machine you run DB2 on I guess,
You pasted to points together though that weren't intended as such;
The one was that even though it doesn't seem like it at times there are other
paltforms out there other than Win95/NT and that there are paying customers who
use those platforms.
The other was that I thought it was kind of shooting with a gun at a fly if you
develop a WinNT app solely because you want to get rid of the 'Out of Memory'
messages of your Dos app...
> >Ehhh, VO used to suck. From what I hear it's a decent tool these days.
> You're reading the wrong propaganda.
Could be Tom. That's why I wrote 'from what I hear'.
Personally I haven't looked at VO since the 1.0a version.
We switched to Delphi for the new developement since then and so far haven't had
a reason to 'look back'.
Anne.
tom leylan
an...@hacom.nl wrote:
>Personally I haven't looked at VO since the 1.0a version.
>We switched to Delphi for the new developement since then and so far haven't
> had a reason to 'look back'.
You're in trouble now... <g>
Tom
Phil Barnett
On Fri, 19 Dec 1997 14:37:26 GMT, tle...@abest.com (tom leylan)
wrote:
>Phil. I'm one of them. I just accepted another contract maintaining legacy
>Clipper code. I spent the last year maintaining legacy Clipper and FoxPro
>code. Why? Because despite the fact that I could have rewritten it for less
>money than it was costing them to maintain the faulty code (this was on the
>last project) they didn't believe it.
I'm three years into maintaining a system that saves the company so
much money that there is no probable end to it's use. It distinctly
and eloquently answers the business problems at hand. There is no real
push to move it into another paradigm, because it is so damn good at
what it does.
It's Clipper, and it's an outstanding model for business. It's still
being sold as a Clipper app, and is currently being revamped by the
company in Canada to a new language. Which one? Delphi and Informix.
>They _didn't_ solve the business problem at hand but clearly somebody who
>either doesn't know the truth and doesn't want to know the truth thought it
>was in their best interest to make sure that everybody else thinks nothing is
>going to be better than the collection of stuff they have at the moment.
According to Yourdon in his book, Decline & Fall of the American
Programmer, he states: (great book, by the way)
"In any reasonable situation, nobody is going to argue against an
assertion that high-level languages are better than low-level
languages. However, such an argument typically ignores the problem of
maintaining existing programs written in older languages during the
last 20 years. Since we're spending between 50 and 80 percent of our
MIS budget maintaining these old systems, perhaps that is what we
should be focusing on. Upgrading the old programs from a 3GL
technology to a 4GL technology may be a great idea, but the focus has
to start with the existing programs, in whatever generation of
programming language they were written in."
"Similarly, the argument about newer and better programming languages
typically ignores the problem of retraining existing programmers who
have spent the past 5 to 10 years muddling around in their old
languages. An upgrade from COBOL'74 to COBOL'85 is hard enough for
these folks; an upgrade from COBOL'85 to object-oriented COBOL is
likely to knock their socks off. An upgrade from FORTRAN to Ada, or
from Pascal to Smalltalk is equally mind-blowing. An upgrade from C to
C++ may apear simpler, because C is a proper subset of C++, but of
course, this just masks the problem - old programmers may continue to
write old programs in their new language. In any event, a new language
is typically not something you can just drop into the organization the
way you might replace an 80286 PC with a 80386 or a Mac Plus with a
Quadra unless you give the existing programmers a lobotomy and
"refresh" their memories with the elements of a new programming
language; it's going to be an expensive, time-consuming process."
You are apparently blessed in many ways, Tom: You are smart enough to
absorb a new language with little difficulty, and you are not steeped
in an organization that is so big it moves ever so imperceptably when
it does move. A vast majority of programmers in the world do not have
your advantage. You are lucky. You didn't choose your abilities. They
are a gift. You probably did choose your circumstances, and that is as
it should be. You can change quickly and adapt quickly because of who
you are and where you are. It's unrealistic to believe that even a
full percent of other programmers have that luxury.
>I really just wanted to post the numeric results all this chatter is of no
>interest to me but I appreciate your reply.
Well, I thought it was cool that it was THAT much faster. Actually
quite amazed.
Frank
V.Kazimirchik wrote:
>
> tom leylan wrote:
> [wire cutters applied]
> >
> Please also post a Clipper/Delphi comparison test based on your
> 'jerks list' search query...
Here's another one for your list.
> --
> Sorry, couldn't resist. Vladimir.
Vladimir said it for me.
--
--------------------------------------------------------
Don't press REPLY mail -- your mail will end up in the
outer space, try the real one -> fkjaer @ online.no
--------------------------------------------------------
Dave Pearson
On Fri, 19 Dec 1997 18:41:13 GMT, tom leylan <tle...@abest.com> wrote:
> da...@hagbard.demon.co.uk wrote:
>
> >This is just plain wrong. If you are talking about what can be done with the
> >tool "out of the box", then yeah, I'd pretty much nod in agreement as you
> >say the above, however, if you are talking about doing the above with the
> >correct tools for each language (correct tools for Pascal, correct tools for
> >Clipper) then I'd have to disagree. Where I work, we've got the framework
> >for doing the above in a Clipper app in not too many lines of code. Perhaps
> >slightly more than the respective Delphi app, perhaps less, but it wouldn't
> >be a 2K one week+ solution.
>
> But Dave <g> you don't get all the Clipper work filtered thru "where you work"
> do you?
I wish. :-)
> Rather than just nitpick I'll ask if your routine supports long file
> names?
Granted, it doesn't, but it could. (no selling, no value judgement, simply a
fact). I wouldn't bother doing it though.
> If so, I'll ask how many other Clipper developers do you imagine have such
> a module?
Very few I would imagine. However, all I was commenting on was the fact
that:
> Of course I'm generalizing,
That's it.
> if we all spoke in absolute terms we couldn't possibly speak since
> somebody would always be able to say, "I wrote <blah> in interpreted
> <bleep> on a <blech> and it ran twice as fast as <bling> on <bloop>."
> Simply substitute a very good blah programmer and powerful blech and a
> poor bling-head using an old bloop.
This reminds me of an episode of Babylon 5. :-)
> Let me try and narrow what seems to be yet another point of
> miscommunication... in Delphi you pick up a pre-built, pre-tested
> component for choosing files and you drop it on a form. It is
> controllable and modifiable but it does most of what people want done
> right off the bat AND everybody who has Delphi has access to it they don't
> have to ask Dave to send his code along.
Like, duh. :-) Yeah, I know, I've played with Delphi, VB, Progress,
Powerbuilder. I don't recall ever once doubting this (preaching to the
converted, remember?). All I was saying was the mildly derogatory statement
re: "the Clipper guy" wasn't quite spot on, it was too general. However, I'm
sure you'll note that I said that "in general" you were indeed correct. It
was simply a observation.
> Using these types of common dialogs people who wrote apps in Win 3.1
> noticed that they immediately had the Win'95 look and feel without any
> additional work. This is traditionally considered a good thing but surely
> we can get a comment from Joe Bob Tubbs who will explain how I've never
> been to Tennessee where all his clients there hate Win '95, think Clipper
> is the greatest and that I have no idea what "real" programmers do for a
> living.
While this is nice, it is totally unrelated to what I was saying. Tom,
please, once again, I'll repeat. I know! I know about Windows, I know about
Clipper, I'm not wedded to Clipper, I'm not defending Clipper, I'm not
selling anything. You might want to think I am, but I'm not.
> >In terms of getting the correct *technical* solution (that it, it works
> >well, it is secure, it is fast, etc) then benchmarking things like
> >database access are important for a specific solution.
>
> DBF files are both insecure and suffer horribly from the lack of
> referential integrity. A wrong answer fast is no answer at all.
Show me where I said anything about using DBF files.
> You're reiterating standard benchmarking questions. Most have been
> answered in reasonable terms by people/companies that develop benchmarks.
> You might as well ask "what language" and question whether lexical scoping
> or object-orientation or virtual memory, or multi-splay arrays or any
> other single thing is "important."
Good, you get that point.
> Is it important if Clipper has a SET function which returns current
> settings, surely somebody who uses an old version of dBASE can say he was
> quite able to write apps without it. Does that negate the relative
> importance of a SET function? Of course not unless you have some vested
> interest in making certain your tool wins the contest.
Total rubbish. Again, you are coming at this from the assumption that I want
to "make Clipper win". Tom, you've even said it yourself, when working in an
environment like Windows (or OS/2, or Un*x, environments that make modular
development so much easier) there is no reason to be wedded to one
particular tool. You know the sort of thing, write the data entry and
manipulation in VB or Delphi, do the reporting and enquiry in PowerBuilder,
do some other bits using the Office suite. Look at each job to be done,
consider the abilities of each of the tools you have available and then pick
the right one.
So, here I am saying "don't be wedded to one tool", suggesting that people
consider all the angles when considering the right tool for the right job,
and you conclude that I'm saying that all tests should be done in such a way
as to make sure "my tool" wins.
> >(For general consumption, not in direct response to Tom) Benchmarks are fun,
> >but that is it. They serve no other purpose *unless you do them yourself*
> >and *in the context of the solution you are attempting to provide*. And,
> >even then, you have to ask the right questions and draw the correct
> >conclusions. Anyone why thinks this thread is anything serious is missing
> >the point and missing it in a big way. To see how misleading all of this is
> >look at the Fibonacci benchmark I posted the other day. Depending on which
> >way you look at it, Clipper blows xBase++ out of the water. To think in
> >those terms would be to mislead yourself.
>
> Well I disagree.
Ok.
> Benchmarking isn't something a few people in a newsgroup decide upon.
Huh? Ok, so you disagree, but, what does this have to do with what I said? I
didn't say along the lines that a few people in a group should decide on the
benchmarks. What I said was, when "benchmarking", the best person to
consider such tests and the best person to conclude the results, in a given
situation, for a given problem, is the person who is attempting to solve the
problem. Testing in context. No selling, no value judgement, just my
opinion.
BTW, just to make it explicit, the above paragraph works all ways for all
tools. (ObRepeat: This is not a defence of Clipper, there is no defence).
> If you think that interpreted BASIC is going to surpass Clipper in a
> fundamental test of execution speed if you just look at it a special way I
> think you'll be disappointed. And I will state categorically that if
> Delphi returned 60 seconds and Clipper returned 1.4 nobody would post
> "benchmarks don't have relevance."
<Sigh> Oh for gods sake Tom! You really haven't read what I wrote have you?
Either that or you've decided what I was trying to say before you read my
followup. What was it you said? "Hit reply before reading"? Never once did I
complain that Delphi was faster than Clipper in some speed test (like this
is news!). Look:
> >This is why I think Tom was partly wrong in his post (at least in the
> >quoted paragraph). He correctly showed that at the end of the day
> >benchmarks don't count for much "in the real world", I'm just suprised
> >that he attempted to conclude his post with another bogus benchmark that
> >appears to be based on suspect data. :-)
>
> You're still hoping that Clipper will outperform Delphi and it won't.
No Tom, you are still hoping that that is what I'm trying to say. Please,
remember, I never took part in the speed tests. Right, got that one? Ok, my
take on the speed tests were that they were intersting, only in their own
right. When you posted the speed test for Delphi my reaction was "yup, not
at all surprising". My reaction wasn't "hell, Delphi is faster, I've got to
attempt to invalidate these tests now, I must live in denial".
You obviously believe otherwise. In which case, please show me where I did.
> I'm a little slow so if you could explain the difference between "bogus"
> benchmarks and the kind of benchmarks you say don't mean anything we could
> compare the languages again.
The "bugus" benchmark (and remember, that last paragraph was mostly jokey,
hence the smiley) was the 2K job thing. That was all I commented on.
> Dave... why are you so dead set on pursuing this "Clipper is God" thing?
I'm not. Tom... why are you so dead set on pursuing this "Date thinks
Clipper is God" thing. I've repeatedly asked you to show me where I've said
anything to this effect, you have yet to do so. I've repeatedly stated that
this isn't my position, you've repeatedly ignored it.
> Pick your fastest Clipper routine and I'll see what I can do to stomp it.
> I don't want it to be bogus so you pick it.
This just shows that you've not really read anything I've been saying. So,
your tool of choice is going to be, what, Delphi? Right, this is exactly
what I was saying. OBVIOUSLY, just about every possible and conceivable
routine can and will be developed and will run quicker in Delphi (well,
apart from pure code, then it is our respective WPM that comes into it),
THIS IS NOT NEWS (preaching to the converted). I don't doubt it, I KNOW it
(preaching to the converted). Never once have I doubted this and never once
have I said "not fair, you are showing that Clipper is bad".
Let me see if I can make this simple for you. Clipper has a problem domain,
Delphi (read, most Windows RAD style tools) have a problem domain. Over the
last few years the problem domain of Clipper has reduced in a big way, taken
over by the expanding problem domain of the Windows tools. With me so far?
Right, all I said was, to compare Clipper against a Windows RAD tool when
the probem at hand is well within the WinRAD problem domain and well outside
of the Clipper problem domain is just plain silly. I say that, not because
it is "unfair to Clipper" (it isn't), but because it is simply an
irrelevance to the thought process you go thru when selecting the right
tool.
Hence my "Linux driver" comment. As I pointed out earlier, it was not a
tactic in diversion or anything. It was simply a statement of fact, even
considering bog standard CA-Clipper as a tool for a fully internet/intranet
connection GUI database application is like considering Delphi for writing a
Linux driver. With enough time and effort it could probably be done (it
generates Intel code, right?), but to consider doing it would be
lunacy. Considering bog standard Clipper for that internet/intranet app
would be lunacy also.
I'm suprised that I need to be this verbose with you Tom.
Dave Pearson
On Fri, 19 Dec 1997 14:50:56 GMT, tom leylan <tle...@abest.com> wrote:
> ><NITPICK>
> >Has Clip4Win ever "come with" CA-Clipper?
> ></NITPICK>
>
> Okay you're off my list <g>
Can I have a button for my web page?
"Shortest time on Tom Leylan's Jerk List Award"
Please? Please?
> You make me laugh Dave...
That's twice this week I've been told this, jeez, nobody takes me seriously
any more.
:-)
Dave Pearson
On Fri, 19 Dec 1997 19:48:54 -0800, Gordon Hamm <v...@astoria.com> wrote:
> I think that is why so many of you use things like Fivewin and Clip4win.
> You think you are doing well by leveraging on your clipper knowledge, but
> in reality, by the time get done hard coding a windows app (16 bit I might
> add), you could have learned an elegant language like C++ or Delphi.
Why the assumption that, just because someone uses CA-Clipper (plus add-ons)
or some form of Clipper derived tool, they don't know wny other language?
> I still believe in using DBFS and not convinced that everything needs to
> be "SQL" .
ObNitPick: DBFs are a file format, SQL isn't. Apples and oranges.
Dave Pearson
On Sat, 20 Dec 1997 07:45:22 GMT, Dave Pearson <da...@hagbard.demon.co.uk> wrote:
> I'm not. Tom... why are you so dead set on pursuing this "Date thinks
> Clipper is God" thing. ^^^^
Saturday mornings are never good, look, I can't even spell my own name
now. :-)
Will Chapman
On Wed, 17 Dec 1997 23:13:07 GMT, tle...@abest.com (tom leylan)
wrote:
>Dave, please you win. You care so desperately I can't stand it. Yes,
>everybody who uses Clipper today is going to be writing Linux drivers next
>week and nobody will be writing Windows database apps.
>
Excuse me for butting in but IMO Dave never even remotely suggested
anything like what you seem to need desperately to argue about.
Frankly, Tom I found the beginning of this tread quite informative but
since you've gone off on a tangent flapping your lips about how, in
your opinion, Delphi is the best thing since sliced bread, I'm afraid
you've lost me.
I'm sure Delphi is a great product although I haven't tried it and
don't need to because I happen to think that VO2 is the better option
for someone going from Clipper to Windows. And if that prompts you to
start a thread to 'prove' that that isn't the case - fine, I'd be
interested to read you opinions (preferably non-emotively and could I
ask that you read the responses a bit more carefully?).
>
>I remain dumbfounded... oh, and I've got a new jerk to add to my list.
>
When I see comments like that I conclud that there is only one kind of
those around here - those that call anyone who doesn't agree with the
a derogatory name. Tom, you discredit your otherwise good name.....and
a full apology would be appropriate.
Try and have a relaxing Christmas, it'll do you good...
Cheers..........Will
Have you seen KnowVO, the VO Knowledgebase?
Visit http://www.knowvo.com/kb/ and add
your favourite VO resource to the collection.
tom leylan
WillC...@dial.pipex.com wrote:
>Excuse me for butting in but IMO Dave never even remotely suggested
>anything like what you seem to need desperately to argue about.
Of course he did. Please take a moment to re-read the messages and you will
find Dave introduced the phrase "Linux device drivers" into a thread that had
nothing to do with Linux, devices or drivers.
It is standard befuddlement tactics... then somebody says "well we could all
write in assembler" and again you'll notice somebody did in fact bring that up
as a solution for calculations despite the fact that I got some 5000 percent
increase without resorting to assembler at all.
>Frankly, Tom I found the beginning of this tread quite informative but
>since you've gone off on a tangent flapping your lips about how, in
>your opinion, Delphi is the best thing since sliced bread, I'm afraid
>you've lost me.
Frankly Will, I think you punctuated incorrectly, but I never ever in my life
flapped my lips about how Delphi is the best thing since sliced bread. I
applaud your willingness to stretch the truth to support your dying product of
choice but I am disappointed at how obvious you made the attempt.
>I'm sure Delphi is a great product although I haven't tried it and
>don't need to because I happen to think that VO2 is the better option
>for someone going from Clipper to Windows. And if that prompts you to
>start a thread to 'prove' that that isn't the case - fine, I'd be
>interested to read you opinions (preferably non-emotively and could I
>ask that you read the responses a bit more carefully?).
I think the last few years of VO-chat have pretty well proven that nobody is
actually willing to "discuss" it. Everytime somebody who used VO left the
fold they were instantly demoted to a "boob." People who wrote books about
Clipper and VO and who's conferences, courses and products people raved about
were instantly "persona non grata" when they mentioned they had transitioned
to other products. If it was Delphi they were taken in by the glitz, if it
was VB they were taken in by the MS advertising machine.
You can't speak rationally to zealots.
>When I see comments like that I conclud that there is only one kind of
>those around here - those that call anyone who doesn't agree with the
>a derogatory name. Tom, you discredit your otherwise good name.....and
>a full apology would be appropriate.
Grow up.
tom leylan
da...@hagbard.demon.co.uk wrote:
>Yeah, I do cringe about this too to some degree. That said, if something
>comes of the likes of xBase++, this really isn't a problem. If people want
>to keep their code blocks, they can keep them. And, this, to a large degree,
>is the point I've been getting at. Windows is the solution for a large
>number of problems, you've said so yourself. The language/tool is
>secondary. So, if xBase++ matures into a solid platform, Clipper is still an
>option, just another tool for the Windows developer and a known quantity for
>those who like their Clipper code. Again, this isn't "selling Clipper", it
>isn't any kind of value judgement, it is simply a statement of fact.
Uhhh... Dave 20 years from now somebody will introduce ClipObj+++ and
a handful of folks will write "the great thing is you can still compile your
Clipper code."
Let's drop the language nonsense and you can speculate on a business problem
with me... how long do you think it takes for any product and in this case
something like xBase++ to (in your words) "mature into a solid platform?"
I should check back for signs of maturity in 6 weeks? 52 weeks? When Version
2 is released, when the xBase++ For Dummy's book is published?
>Hmm, well, you can count me out of that. I didn't make any kind of value
>judgement about the speed tests either way. Come to think of it, I don't
>really recall anyone doing so, a couple of people did follow up with ideas
>about "better" tests but I don't recall any "Clipper lost so it doesn't
>count" kind of messages. Indeed, the speed tests, AFAICT, were posted more
>out of curiosity as to how "fast" xBase++ is compared to good old
>CA-Clipper. Again, I don't recall any value judgements been made.
Well okay... so the real power was demonstrated by shelling out and running a
DOS program written in C and proving that Clipper could send e-mail. Had
somebody demonstrated the inherent power of interpreted BASIC by shelling out
and running a Clipper .EXE would you be equally impressed?
Can you name a language that doesn't have this type of incredible power?
tom leylan
an...@hacom.nl wrote:
>As far as the dumping/asking to leave is concerned; depending on your POV some
>of your posts can indeed be read as one of those 'why are you idiots still
>using CLipper, product X is much better.' posts that we've seen many of before.
The point of view from somebody who thinks I'm calling them idiots for using a
tool which I continue to use is of little interest to me.
What is "idiotic" is to claim it is the "fastest" and then to pooh-pooh every
other tool which is faster. I'm sure the folks on comp.lang.interpreted.basic
would be happy to defend themselves against the Clipper folks who claim they
can perform a task faster than BASIC. Perhaps they will simply claim they're
being called idiots.
<I wrote>
>> But Delphi isn't the way to go when moving to Windows. Windows is the way to
>> go when developing business apps.
<you wrote>
>And even that can be disputed, depending on what platform the client is
>using...
So the same goes for Clipper right? We're working on the fact that the VAX
version of Clipper hasn't been delivered yet.
>I've been talking to a friend who works for a data-processing company.
>They used FoxPro to process the data in the Dbf's because FoxPro is/was? one of
>the fastest tools around and speed is their main problem.
Doesn't that constitute some sort of benchmark?
>They are moving towards Visual FoxPro now and I was wondering how Visual FoxPro
>relates to Delphi for example. I've never done any work with FoxPro myself, nor
>any serious work with Delphi, so I can't tell from own experience how the two
>would relate, specially where speed is concerned.
Well we're back to a central question? Why if FoxPro is the fastest and speed
is their main problem would they move to Windows if (as has been posted)
Windows is inherently slower.
How do they make the switch to VFP (if speed is important) without comparing
relative speeds (we call that a benchmark) of VO, VB and I guess the currently
unreleased xBASE++. It sounds like they're making the switch without regard
to the impact of speed.
>BTW, have you ever looked at XBase++ ?
>I would be interested in knowing how that relates to Delphi too...
I didn't care about VO and I couldn't care less about xBase++. Is there
something particularly cool about using tools that nobody uses?
>Speed matters, but often is only part of the picture.
>I for example am willing to lose some speed if my app becomes easier to
>maintain.
Well how do you feel about gaining speed even as the app becomes easier to
maintain. I'm suggesting that modern tools and as such modern tool users have
benefited from the experiences of the tool developers of the past. Whatever
was wrong with Clipper S'87 was improved in 5.0 and the things we would have
loved to have in DOS-based development has been improved and standardized in
Windows-based tools.
John P. Marshall
Tom,
[snip]
> >Ehhh, VO used to suck. From what I hear it's a decent tool these days.
>
> You're reading the wrong propaganda.
Actually VO2 is a very nice development tool... I had my share of problems
with VO 1.0-1.0b but have _really_ enjoyed programming in VO2... I even
like the repository!
Regards,
John
--
John P. Marshall
I.S. Associates
http://www.isassoc.com/voscript
http://www.knowvo.com
tom leylan
"Gordon Hamm" <v...@astoria.com> wrote:
>I find this argument funny.. It's not really an argument.. Because you
>are so wrong about everything you are saying.. I would love to see you state
>these things in ANY technology/ Computer magazine, they would laugh you to
>scorn..
I call it something like "centricism." It is the uncanny ability to look
backward (in magazines and articles) and laugh at how naive "those people"
were to believe that Cobol or BASIC was "great" and in the same breath look at
people who suggest 32-bit and GUI apps are great and say they too are naive.
No matter where these people are it is the center of the rational universe.
Gordon Hamm
>> I still believe in using DBFS and not convinced that everything needs to
>> be "SQL" .
>
>ObNitPick: DBFs are a file format, SQL isn't. Apples and oranges.
True,
I meant to say, that most of my components that I write are using Small
databases, and hence, DBFs works great.. to use SQL commands in say an
access database or SQL server database to me would be over kill. For
instance, most of my web ISAPI databases are normally less than 8 meg, so
why use all this other overhead .. Oracle, SQL Server etc....
thats what I meant...
Gordon
tom leylan
>> You think you are doing well by leveraging on your clipper knowledge, but
>> in reality, by the time get done hard coding a windows app (16 bit I might
>> add), you could have learned an elegant language like C++ or Delphi.
>
>Why the assumption that, just because someone uses CA-Clipper (plus add-ons)
>or some form of Clipper derived tool, they don't know wny other language?
See Dave you're doing it again. I don't speak for Gordon but he didn't
"assume" anything you did. You're accusing him of assuming it, he never
assumed it but if we can get enough people to accuse him of assuming it then
we might be able to string him up or at least run him out of town.
Gordon is reflecting back snippets of things he reads just as I do, people use
the "xBase++ is like Clipper" and "VO is like Clipper", the "retain your
knowledge" argument so it is OBVIOUS that "learning a new language" is an
issue.
tom leylan
da...@hagbard.demon.co.uk wrote:
>What I said was, when "benchmarking", the best person to
>consider such tests and the best person to conclude the results, in a given
>situation, for a given problem, is the person who is attempting to solve the
>problem. Testing in context.
And what I said was this isn't the case, you're mistaken. Benchmarking, like
good design and like product testing is a learned skill and not something
that programmers just naturally know how to do. It is a professional
undertaking.
The person you describe is simply not adequately trained to devise the
tests or to make conclusions on anything but the simplest of tests and in
those tests the results don't really matter.
You're describing some sort of "product evaluation" but that isn't the same
thing. A poorly tuned version of Oracle is going to be slow. If it is
difficult to tune (and requires a specialist) it might make Oracle a bad
choice but not because it fails a benchmark but rather because it fails the
"product evaluation."
The reasons to use FoxPro or Clipper or Paradox for that matter are typically
devoid of benchmark performance and almost always made on familiarity,
advertising and price. The two concepts are mutually exclusive.
>My reaction wasn't "hell, Delphi is faster, I've got to
>attempt to invalidate these tests now, I must live in denial".
I believe you posted "benchmarks don't count for much", they do, they're
called benchmarks and they give us a "benchmark." When you purchase a
computer you don't start thinking about a 66MHz machine and see it might
perform your specific tasks faster than a 166MHz machine. You rely on the
benchmark which clearly shows the 166MHz to be faster on a given set of tasks
that your software is likely to perform.
It is possible that a 133MHz machine could outperform a 166MHz machine on a
specific test. Then if it was that kind of task that you were doing most of
you would likely look at the 133MHz closely despite it being slower overall.
In every case a benchmark is used to narrow down the "infinite" number of
possibilities to a manageable number.
>Let me see if I can make this simple for you. Clipper has a problem domain,
>Delphi (read, most Windows RAD style tools) have a problem domain. Over the
>last few years the problem domain of Clipper has reduced in a big way, taken
>over by the expanding problem domain of the Windows tools. With me so far?
The problem domain of modern tools encompasses the problem domain of most
older tools. They are developed that way. No company is determined to cut
off their current installed base (CA not withstanding.)
>Right, all I said was, to compare Clipper against a Windows RAD tool when
>the probem at hand is well within the WinRAD problem domain and well outside
>of the Clipper problem domain is just plain silly. I say that, not because
>it is "unfair to Clipper" (it isn't), but because it is simply an
>irrelevance to the thought process you go thru when selecting the right
>tool.
You're defining the "Clipper" argument even if you don't realize it. While
the immediate problem might be "I need 20MB of disk space" you can't suggest
anybody go out and buy a 20MB hard drive. That solution is however, within
the problem domain.
If somebody wants x, y and z capabilities and you can not only deliver that
but also 12 things they might want next year and 3 things they hadn't thought
about but can use immediately and in less time then the problem domain wasn't
what you originally pidgeon-holed it to be.
>Hence my "Linux driver" comment. As I pointed out earlier, it was not a
>tactic in diversion or anything. It was simply a statement of fact, even
>considering bog standard CA-Clipper as a tool for a fully internet/intranet
>connection GUI database application is like considering Delphi for writing a
>Linux driver. With enough time and effort it could probably be done (it
>generates Intel code, right?), but to consider doing it would be
>lunacy.
Delphi has a built-in assembler... you can write ASM code if you want. If
Clipper had a built-in assembler I wouldn't consider it lunacy to write a
Linux driver using it.
All I have done is state facts. You mostly state opinion, "the right tool",
"your own special needs", "problem domain", etc.
If you say "fast is good" then I say "let's time them" if you say "small is
good" then I say "let's see which is smaller" if you say "cheap is good" then
I say "let's compare the price."
If not you specifically and pardon me if you thought only you and I were
conversing here, then others are saying "Clipper is faster, smaller, cheaper"
and I'm saying no it isn't.
But I've got to go... I've spent a couple of hours on this group this morning
alone and I get nothing out of it except being called names and personally I
don't find that particularly fun.
tom leylan
"John P. Marshall" <j...@isassoc.com> wrote:
>Actually VO2 is a very nice development tool... I had my share of problems
>with VO 1.0-1.0b but have _really_ enjoyed programming in VO2... I even
>like the repository!
Thanks... so is Clarion, DataEase, Visual Basic, PowerBuilder, Delphi, Visual
FoxPro, Visual dBASE, R-BASE and if you stop by the Java newsgroups, Java is
poised to take over the world.
Gordon Hamm
This is what I find funny .. (Will, you and I have had discussions before
about this )
The old saying "There is safety in numbers" is real when discussing Software
development.. you might be right, VO may be a better tool, but there are
only a handful of people in the world using VO... Thats what concerns me..
You are very loyal and thats good but I think you have to look at VO for
exactly what it is..
Dev tools are short lived enough all by themselves, why do you want to go
with a minority product? I know Ive said this before, but just look at the
one and only VO newsgroup.. there are about 10-15 new messages a day..
Look at Delphi, about 10-12 newsgroups, each with 100's a day..
Wouldn't you want to lean on that kind of resource ??
--
Gordon Hamm
Voice Data Systems Inc.
Astoria Communications
360-686-8315
Will Chapman wrote in message <349ebc94...@news.dial.pipex.com>...
>On Wed, 17 Dec 1997 23:13:07 GMT, tle...@abest.com (tom leylan)
>wrote:
>
>
>>Dave, please you win. You care so desperately I can't stand it. Yes,
>>everybody who uses Clipper today is going to be writing Linux drivers next
>>week and nobody will be writing Windows database apps.
>>
>Excuse me for butting in but IMO Dave never even remotely suggested
>anything like what you seem to need desperately to argue about.
>
>Frankly, Tom I found the beginning of this tread quite informative but
>since you've gone off on a tangent flapping your lips about how, in
>your opinion, Delphi is the best thing since sliced bread, I'm afraid
>you've lost me.
>
>I'm sure Delphi is a great product although I haven't tried it and
>don't need to because I happen to think that VO2 is the better option
>for someone going from Clipper to Windows. And if that prompts you to
>start a thread to 'prove' that that isn't the case - fine, I'd be
>interested to read you opinions (preferably non-emotively and could I
>ask that you read the responses a bit more carefully?).
>
>>
>>I remain dumbfounded... oh, and I've got a new jerk to add to my list.
>>
>When I see comments like that I conclud that there is only one kind of
>those around here - those that call anyone who doesn't agree with the
>a derogatory name. Tom, you discredit your otherwise good name.....and
>a full apology would be appropriate.
>
Will Chapman
On Sat, 20 Dec 1997 16:16:32 GMT, tle...@abest.com (tom leylan)
wrote:
>I think the last few years of VO-chat have pretty well proven that nobody is
>actually willing to "discuss" it. Everytime somebody who used VO left the
>fold they were instantly demoted to a "boob." People who wrote books about
>Clipper and VO and who's conferences, courses and products people raved about
>were instantly "persona non grata" when they mentioned they had transitioned
>to other products. If it was Delphi they were taken in by the glitz, if it
>was VB they were taken in by the MS advertising machine.
>
Not in my book - I'm a great believer in each person using the tool
that best suits one's purpose. It would be a sad, inadequate world if
there was only one development tool available and if you chose to go
with Delphi I'm sure that it was well considered.
After experiencing the horros of the VO pre-release (and indeed VO
1.0!) I can well understand why many people dumped it. There is also
the big question of whether CA are giving it all the support/push they
need.
However, I can assure you that the admitted problems of the
pre-release are past history and VO 1d is now very stable and, more,
important, VO2 is a delight to work with and truly has all of the
power and elegance that many of us enjoyed and appreciated in Clipper.
What I'd really like to see is a real (preferably non-emotive)
exchange that truly highlights the strong and weak points of each
product - something like that would give those that haven't yet made
the move to Windows development a fair and honest catalogue of pros
and cons from which they can make their choice of developement tool.
I thought your undoubted knowledge of Clipper and enthusiasm for
Delphi would place you in good stead to highlight the strong points of
Delphi as a Clipperhead would see them - you know, all the old
chestnuts, mixed & ragged arrays, codeblocks, database RDD's, re-use
of legacy code and data etc., etc. Not forgetting, of course, the
ability to take full advantage of whatever the Windows API has to
offer.
Perhaps the bottom line question is: Is there anything that you can do
with Delphi that you can't with VO2 and vcie versa. AS far as I am
aware, the only serious lacking in VO2 at the memnt is that it has
problems with some OCX's - however, I'm confident that will be sorted
out in the next one patches (expected imminently) or, latest ver 2.*
which is promised (?) for in April.
>You can't speak rationally to zealots.
>
Couldn't agree more .. despite what anyone says, they always go back
to the point that they believe in so strongly, which, by definition,
means their ability to reason is clouded by emotion.
>> Tom, you discredit your otherwise good name.....and
>>a full apology would be appropriate.
>
>Grow up.
No Tom, I'm trying to have an adult conversation, it is you that is
reacting below your age......now do you want to be serious or shall I
continue this conversation elsewhere? (which would be a shame becuase
I value your opinion).
tom leylan
WillC...@dial.pipex.com wrote:
>tle...@abest.com (tom leylan) wrote:
>>Everytime somebody who used VO left the fold they were instantly demoted to a "boob."
>Not in my book - I'm a great believer in each person using the tool
>that best suits one's purpose.
You perhaps missed the multi-hundred message threads on CIS and
the proportionally (smaller) sized ones here then. People like Rick Spence
and Greg Lief were vilified when they revealed their decision to abandon VO
because it was (to paraphrase) "unworkable in the realworld."
By that they clearly meant, no vendor support, no book publisher support,
little interest in the business sector, etc., etc. All valid statements of
fact yet the name calling continues to this day.
>However, I can assure you that the admitted problems of the
>pre-release are past history and VO 1d is now very stable and, more,
>important, VO2 is a delight to work with and truly has all of the
>power and elegance that many of us enjoyed and appreciated in Clipper.
Great, for a few thousand people the years of waiting has paid off. It is
unlikely however that any large contigency will abandon whatever alternatives
they found in favor of CA-VO.
>What I'd really like to see is a real (preferably non-emotive)
>exchange that truly highlights the strong and weak points of each
>product - something like that would give those that haven't yet made
>the move to Windows development a fair and honest catalogue of pros
>and cons from which they can make their choice of developement tool.
It can't be done. If I list "abc" has been available in Delphi, VB or C++ for
5 years the counter argument is that it will be available in the next version
of VO and that is considered "a match." I understand that VO classes
generated by VO must be sub-classed because any code the user adds will be
destroyed when it is rebuilt. These types of limitations were overcome in the
first version of Delphi and other tools.
Here's the VO reply, "Well we like it that way", "It's actually better that
way", "you learn to work around that", "Delphi has it's own sets of problems",
"yeah well somebody I know, knows somebody who used Delphi and still hasn't
finished their application."
This is really productive reasoning right?
>Perhaps the bottom line question is: Is there anything that you can do
>with Delphi that you can't with VO2 and vcie versa. AS far as I am
>aware, the only serious lacking in VO2 at the memnt is that it has
>problems with some OCX's - however, I'm confident that will be sorted
>out in the next one patches (expected imminently) or, latest ver 2.*
>which is promised (?) for in April.
Probably... I could drop an OCX component a couple of years ago on a Delphi
form and I can drop Active-X components right now. I'm not promoting Delphi
however so most of the arguments about VO vs anything are moot.
The point has always been, there are now non-Clipper tools that are superior
to anything that Clipper has to offer (with the possible exception of those
people who have to maintain '286 compatibility.)
>No Tom, I'm trying to have an adult conversation, it is you that is
>reacting below your age......now do you want to be serious or shall I
>continue this conversation elsewhere? (which would be a shame becuase
>I value your opinion).
It can't happen Will. Again, I don't care what people develop in, all I tried
to do was point out that a 5 or 10 second decrease in speed is a poor goal
when reasonable alternatives exist that reduce the time by a factor of 50.
Do me a favor, compile the prime number benchmark and post the results and
we'll start from there. Every list of benefits that I have seen posted about
CA-VO has included "32-bit native code compiler" so I'd like to see a hard
fact at some point.
Hopefully I'll get somebody to compile it in VB5 and then we can get a bunch
of people saying "har, well sure if you want program in BASIC" like Clipper is
the future and BASIC and Pascal are denizens of a dark past of programming
that nobody wants to talk about. After a couple of messages you'll see the
"Linux device drivers" thing appear again, somebody will write "why don't you
just use assembler" and nobody has learned a thing.
Post the code and the prime number timing results for CA-VO.
tom leylan
da...@hagbard.demon.co.uk wrote:
> I'm not painting any picture, you are the
>one with the brush in your hand dawbing "jerk" over the group.
For the record, while often accused, I have never "dawbing 'jerk'."
Merry Christmas.
Phil McGuinness
[reply]
I still prefer sliced bread !!
Phil - Sherlock Sherlock. Australia
[snip]
>your opinion, Delphi is the best thing since sliced bread, I'm afraid
>you've lost me.
>
>I'm sure Delphi is a great product although I haven't tried it and
Phil McGuinness
tom leylan wrote in message <67hbdl$s...@news.abest.com>...
>WillC...@dial.pipex.com wrote:
>>tle...@abest.com (tom leylan) wrote:
>>>Everytime somebody who used VO left the fold they were instantly demoted
to a "boob."
>
>You perhaps missed the multi-hundred message threads on CIS and
>the proportionally (smaller) sized ones here then. People like Rick Spence
>and Greg Lief were vilified when they revealed their decision to abandon VO
>because it was (to paraphrase) "unworkable in the realworld."
>
I understand the main reason that Greg Lief moved was two fold ;
1/ was VO1 was not a viable product and he had a business to run and
VO was not viable for him.
2/ Gref said he could not work with CA people and as long as they were
invloved he would not be.
>
> I understand stand that VO classes generated by VO must be sub-classed
because
> any code the user adds will be destroyed when it is rebuilt. These types
of limitations
>were overcome in the irst version of Delphi and other tools.
>
You understand 'wrong'. I do not have to subclass unless I choose to.
The PREINIT and
POSTINIT methods are fanatastic and code added does not overridden as
claimed!
>>Perhaps the bottom line question is: Is there anything that you can do
>>with Delphi that you can't with VO2 and vice versa.
Yeh, I would like to know if I was to drop VO2 and switch to DELPHI what
I could do
better faster, that I cannot already do - easily?
Phil - Sherlock Software - Australia
Phil McGuinness
[snip]
Gordon Hamm wrote in message <349c0...@news1.ltinet.net>...
>This is what I find funny .. (Will, you and I have had discussions before
about this )
>VO may be a better tool, but there are only a handful of people in the
world using VO...
>Thats what concerns me.. You are very loyal and thats good but I think you
have to look at VO for
>exactly what it is..
Only a handful of users/ developers - a bit of an exageration!!. I
attended the recent Technicon in
Melbourne - Australia and VO was alive an well, with many companies
showing off their NEW
VO apps. One user, a doctor had developed an application which recently
won a major award and
he has 3,500 users in the field. Sabo from CA, Ginney Gaughey had come
directly from the German
technicon and there were well over 130 VO developers at this conference.
>Dev tools are short lived enough all by themselves, why do you want to go
>with a minority product? I know Ive said this before, but just look at
the
>one and only VO newsgroup.. there are about 10-15 new messages a day..
When you talked development tools remember that VO out of the box has
just about everything
you need. The only development tools I have needed have been written in
VO and I bought the
source code as well. In the windows environment, Windows is really the
'language' and VO is just
a 'tool' . VO users are not a minority but a member of the whole Windows
environment, which means
we can and are using DLL written in C++, DELPHI, VO etc. By using ODBC,
OCX etc we have all
we need. If JASMINE becomes as big as CA hopes, VO will be a great front
end for the product and
I understand the next major version of VO will have this native support
built in.
>Look at Delphi, about 10-12 newsgroups, each with 100's a day..
>
Wouldn't you want to lean on that kind of resource ??
100's a day says two things - lots of users with questions or lots of
users with problems or both.
The official forum for VO is on Compuserve and this apparently is not
going to change in the short term.
The resource I need is a stable well designed product that delivers an
excellent end result. Clipper
was the same robust, flexible situations and with only a few 3RD party
products still delivers everyday.
There are a number of sites or people I can draw on for information when
required and usually another
persons view point is all that is needed to get around a problem.
tom leylan
"Phil McGuinness" <hey...@sherlock.com.au> wrote:
>One user, a doctor had developed an application which recently
>won a major award and he has 3,500 users in the field.
Phil... could you attempt to actually give a reasonable example? Nobody
who attended Debate 101 would list the end users of a product as proof of a
development product's success. The doctor would have had 3,500 users if he
wrote it in FileMaker Pro.
NetScape has millions of users and they didn't use VO.. proof positive that
not using VO nets you millions of users and using VO nets you 3,500.
>Sabo from CA, Ginney Gaughey had come directly from the German
>technicon and there were well over 130 VO developers at this conference.
Great it took two entire busses to transport all the German VO users.
>If JASMINE becomes as big as CA hopes, VO will be a great front
>end for the product and I understand the next major version of VO
>will have this native support built in.
Obviously if VO had become as big as CA had hoped we wouldn't be having this
discussion.
Since nobody else seems willing to do it, post the results of the prime number
test using VO please.
TSDing
I guess, I would agree that the speed benchmark is not really
the main issue of choosing a development tool.
It is how much a development tool can help us ...
1) Deliver the Apps fast
2) Easy Maintenance
3) Minimize Bugs
Choosing a right tools can make quite a lot of difference in
all these areas. Our company had used many development tools
in the past. At this moment VO 2 is the choice for us.
Many companies here are also starting to use VO 2.
Merry Christmas
TSDing
Will Chapman
On Sat, 20 Dec 1997 20:56:19 GMT, tle...@abest.com (tom leylan)
wrote:
>
>Post the code and the prime number timing results for CA-VO.
I'd be happy to if you could repeat the code (an emial-eon has passed
since it was posted and I've deleted the early part of this thread
which I've taken the liberty of renaming).
Will Chapman
On Sat, 20 Dec 1997 10:35:42 -0800, "Gordon Hamm" <v...@astoria.com>
wrote:
>You are very loyal and thats good but I think you have to look at VO for
>exactly what it is..
>
>Dev tools are short lived enough all by themselves, why do you want to go
>with a minority product? <
Because it works. I haven't found anything that I want to do that
can't be done with VO2 and I can't conceive of anything - and that is
without any third party libraries except VOCom.
Th evry last thing I want to at this stage is to slow up my
development process by switching to another language, this
particulally as so much if it is tied up with lagacy Clipper code.
> I know Ive said this before, but just look at the
>one and only VO newsgroup.. there are about 10-15 new messages a day..
>
As I said before, the merits of a news group in my mind are three
fold:
1. Do its users give me solutions to my probelms
2. Do I learn something by ready about other peoples problems
and 3. Do I have enough time each day to read 2. above <g>
>Look at Delphi, about 10-12 newsgroups, each with 100's a day..
>
See point 3 above.
>Wouldn't you want to lean on that kind of resource ??
Only if the platform I am using doesn't answer my needs. Oh, and by
the way, a sysop just announced that the VOFUM on Compuserve passed
the 100,000 message mark recently, so it is just more than a handful
of us.
Matej Jurac
On Sun, 14 Dec 1997 09:00:03 +0800, TSDing <din...@pc.jaring.my>
wrote:
>Maybe you can put the code to test on the VO 2.0A-1 since it is
>also a variant of the Clipper Language.
>
>Phil Barnett wrote:
>>
>> Compiler Processing Time CPU% .EXE Size
>>
>> Summer '87 I gave up after 30 minutes. 11 165K
>> 5.2 105.67 seconds 100 156K
>> 5.3 61.13 seconds 100 182K
>> Xbase++ 57.79 seconds 100 38K
>
> VO 2.0A-1 ? ? ?
>
NP:
P166/IntelTX/512kCache Win95
Out of IDE: Quicker to do..
GUI/32 App: 22,74s I didn't link it
Terminal/32: 24,99s compiled 31K (after test)
Clipper 5.3 43,28 281K
All VO (1.x to 2.x) are quite slow when perfoming floating point math.
Problem is in func Sqrt(), which is incredibly slow. This is also true
for other floating point functions.
Please don't take me wrong: funcs are faster than clipper's.
Please remove "notrashmail" from notra...@sgn.net and
replace it with matej.jurac for e-mail adress.
Sean Webb
On 12/20/97 6:16PM, in message <67gr11$2...@news.abest.com>, tom leylan
<tle...@abest.com> wrote:
> You can't speak rationally to zealots.
>
Thats exactly why you can be so hard to talk to <g>
Its easy to tell a zealot. They are much like politicians , you pose one question ,
they then either
a) answer a completetly different question
or
b) Ridicule the questioner
or
c) Completely misinterprept the question/statement
or
d) all of the above.
You score on d)
In the good old clipper hay day , you were 'some one of note' at nantucket.
Cool.
But now .....
Just another Delphi Developer.
And just another PC developer that has in the past few yrs discovered SQL and
think its the best thing since sliced bread, when people like myself were using
SQL on mainframes when you were still fiddling around with toy machines like
XT's trying to get clipper 86 & 87 out the door.
--
Sean Webb , Spyder Computing
Security & Risk Management Systems (Shopping Malls, Waterfronts, Guarding
Companies, CBD's ) . Fire & Rescue database applications
Marina Booking Systems , POS developments.
Personal Home page:- http://users.iafrica.com/s/sp/spwebb
tom leylan
WillC...@dial.pipex.com wrote:
>I'd be happy to if you could repeat the code <snip>
I just e-mailed it to you... indenting seems to have gotten wasted when I cut
and pasted but it isn't a particularly long piece of code.