FW: fPSA

[Fairlight]

Is it just me, or did John Esak say:
> working on the project. As for MySQL and other smaller less expensive
> engines... yes, they are probably the best bet for most filePro
> transformations and enhancements... but in this case, it is all about
> implementation. Understanding the full implications of how to design good
> apps with this base is not something that will just "come to you". It takes
> years of learning experience to progress to the same point you (we) are
> already at with our 20+ years of filePro know-how. And truly, MySQL alone is
> not going to do _anything_ for you without a whole slew of other tools, like
> PERL at least. And learning PERL enough to make MySQL do its thing is a
> lifetime career in itself. Sure you can use anything besides PERL, like
> Visual Basic, but the point is, these other ready-to-go database engines are
> not that... ready-to-go. They merely allow SQL-savvy users to use them. This
> may be a plus in today's world... but I discount it pretty heavily, as I'd
> rather have my user-base knowing about my product and their actual business
> rather than how to finagle the data they want out of a database.

A couple of points I'd like to address:

1) You say that the alternative solutions won't just "come to you".
However, you already acknowledge 20+ years' (probably over 25, I'd wager)
experience with filePro.  I can assure you that while I knew BASIC, Pascal,
and C, as well as several shell languages when I started with fP in 1993,
filePro itself did not just "come to me".  And its likelihood of doing so
seems to vary as an inverse proportionate to how many other structured
languages you already know.  Nancy Palmquist has repeatedly told me that
the people that really have the most problems with fP -are- people like me,
who come in from other languages.  While this "coming to you" bit after 20
years of experience is fine for the entrenched crowd, it's off-putting to
fresh blood that might come into the scene late.  And 1993 was already
late--it's now twelve years later still.


2) Learning how to make perl run with MySQL doesn't take a lifetime.  Not
even close.  I started with perl, went through the "Learning Perl" book
in about a month on and off in my spare time, wrote some utilities and
applications, and then bought the O'Reilly MySQL book maybe six months
later when I wanted to expand.  I totally ignored their DBI implementation
for perl as presented in the book, instead using the book to learn MySQL
itself (having been a -complete- newcomer to SQL of any flavour).  I used
the DBD::mysql module instead, and I was up and running with perl and MySQL
within a few days, and corrected some mislearned programatic behaviours
over the next month.  Writing a database-driven web forum system is good
practise and experience for combining the two.  If you have the will to
learn it, it's really not difficult.  I honestly found it easier to learn
that combination than I did to learn filePro.  The documentation available
is certainly better than what I saw with fP Plus v4.1 with the big black
binder manual.  Docs were half the problem with fP, I think--or lack of
decent ones at that time.  Haven't looked at modern versions, so I couldn't
attest to any progress in the form of clarity.

The main difference is really body versus engine, to use an analogy.
filePro has a somewhat antique body, but in many ways, it's like a classic
car in that it still works for you decades later.  The underlying engine
isn't anything all that special, but the body is really nice.  IOW, it lets
you do simplistic to moderately complex UI and report design relatively
quickly as a novice.  More complex Header/Detail design takes a bit
more--more than the corresponding SQL.  But the body is still cool.

MySQL is an engine, pure and simple.  Nothing more.  It doesn't even -have-
a body, but you can get the engine and put it into any body you choose.
And there are some nice bodies out there.  CodeCharge, from what I've seen,
is an incredibly impressive example of one program letting you design a web
site with most of the modern RDBMS engines (pick one, most were supported),
and letting you use any of five or seven of your favourite languages.
Except you don't have to write it -in- that language--it's done visually,
and you can (with the Enterprise version) tell it which set of code to
generate...ASP.NET, Java, Perl, etc.  Actually, the same project can be
generated in all the languages.  Then you can tweak if you still need
to, which I've heard isn't often.  But at its heart, MySQL is only an
engine, and bring your own body.  However, that engine is easily installed
into many bodies with little to no muss or fuss.

Jay may bring up Postgres.  I was forced looked at it when I ported FairPay
to a few engines (mostly data type conversions).  I wasn't impressed from
my standpoint.  MySQL was far easier to administer, and the administration
seemed to make more sense than Pg's model as well, despite some relatively
shortcomings in meeting official standards yet--MySQL is very much still
being worked on.

Don't get me started on MSSQL. :) Besides the usual security debacles, the
only way it's *nix-accessible is through two layers of drivers/managers
combined, and then only via ODBC, which is really dog-slow compared to a
native solution.  This was explained to me as a fault of the standard,
which apparently abstracts the real comms layer by at least two levels,
thus dragging it to a crawl.  Biggest problems I had were with multiple
ODBC cursors.  Ugh.

> You are so right about it being a younger person's game. It's not that I
> don't have the time, I don't have the desire. :-)  Therefore, to accommodate

The younger people, however, also have the time, but not the desire--to go
the other way.  This is where fP will have trouble attracting new
programmers well-versed in modern languages and applications.  And you know
how often younger people feel they're actually wrong.  :) :) :)

> It is SO hard when new blood comes into the company and says... "What the
> hell is fielPro??  Why aren't you using such-and-such???"  All we can do is

Sounds accurate.  :(

> say, "Gee, we'd like to... perhaps, but are YOU willing to put in the 20+
> years developing what we already have to make it worthwhile for us to
> switch?"  At this point, the situation always gets back to reality. In our

Migration is usually harder (and more costly) than ground-up design; mostly
this is due to analysis of the extant solution(s) taking longer than
designing it from the ground up.  If you give someone a specification for
what you need, they can generally do it for you several times faster than
if you have them look at your application (or if you look at your own!) and
try to mimick that in another environment--which may or may not be
as accomodating to some functionality.

In addition, I doubt it would take them 20 years.  You've built a system,
you know what it needs to do, and can write a specification that probably
evolved in spurts sometimes, but probably gradually for 20 years.  You've
already done the design research.  That step out of the way, it would take
far less time to do the actual implementation, assuming it can be done.
Just saying...there's a lot of work that went on in that 20 years that
wasn't pure code--it was figuring out design goals and doing the design.
That eats up a lot of resources compared to coding to a defined spec.

> P.S. - Only one small thing. The company (whoever owned filePro at the time)
> did not actually deceive us regarding ODBC. They never promised anything
> more than client-side ODBC from the very outset. The first investigations
> proved that it would be essentially impossible to implement server side ODBC
> for filePro, and I don't think they ever lied about this. We take what we
> can get. :-)

My recollection is that they promised it to -all- 5.0 licensees, and
then delivered only for Windows-based ones.  I've talked to people that
saw fliers at the Vegas conference that purported this feature while not
mentioning it would be 'doze specific.  So in all, *nix users did get the
shaft--some of which -only- upgraded to 5.0 based on that premise and
promise.

mark->
-- 
          *****   Fairlight Consulting's Software Solutions   *****
OneGate Universal CGI Gateway:                  http://onegate.fairlite.com/
FairPay PayPal Integration Kit:                 http://fairpay.fairlite.com/
RawQuery B2B HTTP[S] Client & CGI Debugger:     http://rawquery.fairlite.com/
Lightmail Mail Sending Agent:                   http://lightmail.fairlite.com/
FairView Image Viewer for Integration:          http://fairview.fairlite.com/