> > - RDBMS. When the day comes that RDBMS's are passé, replaced with 
> > something so good that relational doesn't make sense 
> anymore, then I 
> > would be inclined to agree the genre is dead.
> 
> VFP doesn't even compare with other RDBMS's in common use 
> today. Yes, sometimes the speed is comparible, but the 
> featureset lags far behind Oracle, MSSQL, and MySQL(free 
> versions exist of MySQL and MSSQL; possibly Oracle, but I'm 
> not as familiar).


VFP was never designed to function as a database server, so I don't
consider that a fair comparison. For our market, small business and
niches within large companies, the power of VFP on LANS is just fine,
without our having to resort to high-end ($) products.


> > - Royalty-free. Need I expound?
> 
> What's not? I haven't seen developer tools that are royalty 
> free for a long time. If you're talking the RDBMS, there are 
> very good free alternatives(MySQL/MSDE/SQL Express/SQLite) 
> available for everything that VFP can scale to and even beyond.


But that's the multi-product solution, as compared to the xBase/VFP
"Swiss Army Knife" integrated approach. 

This is a big subject, with room for different points of view. I'm not
against extending a VFP app to ALSO handle data from different sources,
but I greatly prefer to build products that can run standalone and have
minimum dependencies on any other product. It's hard enough to master
and control one product. Being responsible for and having to master and
control multiple products at the development level is a proposition that
I've gone through great lengths to avoid.

 
 
> > - integrated product development system. The 10% at the top of our
> 
> This is very common and has been for years. Not at all unique 
> to VFP or xBase.


My point was that the market, programmers, is heavy in the middle, not
the top, and the 'average' programmer isn't about to become master of
multiple products in any reasonable time frame. Therefore these people
are better served with a "general purpose Swiss Army Knife" that they
can do many things with today and also has plenty of room to grow with
tomorrow.  

 

 
> > - a core language so rich that, after a lot of years, I have yet to 
> > use every feature. There are some frustrations and limitations, but 
> > nothing that can't be fixed or improved with effort. If there were a

> > clearly superior language/RDBMS dev system on the market, I'd have 
> > heard about it, and frankly, I would have yearned to use it, but I'm

> > not seeing such a thing. What I do see are all the things I have yet

> > to do, and can do, with VFP.
> 
> VFP's language is riddled with the curse of 'legacy'. This is 
> just one thing that drags the language down. There are also 
> many, many frustrations and limitations that can not easily 
> be worked around in VFP. One in particular, is the flashing 
> of images with alpha transparency information(png) when 
> lockscreen is set to false. Having not control of the lower 
> level GDI/GDIplus functions used to draw the screen, this is 
> an un-solvable problem.


You're into fancier screen stuff then I'm up to, so I can't offer an
answer to the problem you're seeing. 

As to the "legacy" part, I don't even see it until someone mentions it.
Besides, I assume most of us use some sort of framework that has
wrappers around arcane functions. I rarely write "USE" in code anymore,
it's all calls to my "CONNECT" class, which handles all the details of
making connections, recovery included. But perhaps most importantly is
that we have libraries of code examples that we can put into classes or
just copy/paste, so we don't have to struggle again and again with
nuances after a function is worked out the first time. It's fair to say
that nowadays I spend much more time searching for previously coded
solutions then writing new ones (although I don't mind writing code
either way, I prefer to use the tested code).

I also think that a part of what's perennially called 'legacy' is really
a reaction to "computereze", regardless of the language. I'm quite sure
I could pickup a book on, say, Oracle or SAP, and find commands that are
arcane or even laughable. There just isn't a "pure" computer language,
perhaps save the assembler - which at least is honest about it. The fact
is that we're trying to conduct human->machine dialogs and that's
intrinsically hard to do.
 
 
> > advantages of computers. There are literally billions of people out 
> > there, mostly relatively poor, with a growing appetite for machines 
> > that we take for granted. As the market extends, the favorites are 
> > going to be products that deliver the best value, and nothing on the

> > market says "value" better then VFP (the genre).
> 
> In many of these countries, all the products are 'free'... 
> Hence, they end up with what's popular. Most certainly not 
> VFP(though there are clear exceptions, of course).

 
I've been thinking about Spanish speaking countries (dialect difference
aside), and what a huge market that is for our products and tools (just
need good English->Spanish translators).

 
> > And that's just where the genre stands today. Imagine it being even 
> > better?
> 
> It's dying. xbase is a file-based RDBMS. The years of 
> file-based RDBMS's ruling supreme are far behind us. We're in 
> the time of server-based RDBMS's.

But you know it's also a client for the various backends, thus it's only
real weakness is not being a multi-user server engine itself. And even
that I'd argue is possible (I've long thought that AFP could wrap a copy
of the runtime engine, but I digress ...), but then I'm not claiming VFP
is a high-end DBMS competitor, nor perhaps should it be; but what it
does do is more then enough for many, many applications in a big, big
world.


Bill


> 
> 
> -- 
> Derek
> 
> 
[excessive quoting removed by server]

_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Reply via email to