fP modernization

[Brian K. White]

----- Original Message ----- 
From: "Fairlight" <fairlite at fairlite.com>
To: <filepro-list at lists.celestial.com>
Sent: Thursday, April 27, 2006 2:23 PM
Subject: Re: fP modernization


> Simon--er, no...it was Larry Weaver Sr--said:
>> Although this is likely a prejudiced audience, I know that many of us
>> have wondered where/if fP is going anywhere. How much longer before fP
>> can really get into the fray of the modern technology? Although we have
>> been using fP since TRS80 days, we are wondering if we should continue
>> to put additional time into the programs we have or should we "bite the
>> bullet" and go somewhere else. The next question, obviously, is where do
>> we go? Who has ideas and/or comments??
>
> Although 5.6 had more meat to its features list than I personally expected
> to see, I'm not sure it's enough, nor in time.
>
> My best guess to the answer of how long until fP could really modernize is
> that it depends on revenue from sales.  If there are not enough product
> sales then there won't be enough money to subsidize development.  It's 
> that
> way with any software product at any company.
>
> Personally, from a purely analytical standpoint, I think they'll get 
> mostly
> upgrade sales due to nested calls, added indexes, and 64bit I/O.  Those 
> are
> the three real draws to 5.6, IMHO.  But if the upgrade adoption rate was

Don't you think built-in tcp sort of opens up a whole world of stuff?
Nested calls and large files are enhancements to existing features and 
existing code.

The tcp seems to me like it's a whole new feature that allows and begs for 
whole new applications to be written around it.
Or would you say that you could always have done the same things perhaps a 
little less efficiently and conveniently with system() and user()?
That's not an rhetorical/antagonistic comment but an actual question. I can 
sort of see it that way myself but think once we get coding it'll end up 
becoming a staple.

Then again, I already feel the same way about the generic file i/o commands 
and they have been around a long time now and I know people who still do 
everything with import/export & print to file.
Just for the record, I do use import/export for jobs that they are designed 
for, I don't mean to imply read/write displace all file-io, or even most.
I just wish the file-io had any way of specifying chmod/chown because it's 
really really stupid to have these nice efficient routines that use nice 
efficient built-in fp features for direct file access, and still have to run 
a system command before every action just to ensure the file gets created 
with whatever necessary mode bits. I hope the tcp doesn't turn out to have 
some similar Achilles heel.

> As far as new blood...I'm pretty doubtful there'll be much in the way of
> that.  filePro has been in a rut for pretty much a decade now, the second

I don't really think so. Merely development has been necessarily slow. No 
way around that other than shipping buggy untested stuff.
As you said the other day, they view any real bugs as a major deal and 
surely that takes a lot of work and developer time to track them down.
It's a measure or their track record that I have never had a problem 
upgrading versions on production boxes.
I read the readmes to be warned about known possible gotchas due to new 
features or other changes, and I don't run the installer but manually put 
the files in place, but I do go ahead and put it in and it's never been a 
problem. The same is not true for a lot of stuff out there.
That sort of dependability can't coexist with fast, proliferous, development 
unless you have a very large developer staff and beta tester audience.

There have been a stream of really useful developments. Each one making a 
big difference in overall usefullness. Merely we take them for granted 
quickly after they appear.
Perhaps that's not unreasonable considering the existence of the 
competitions feature sets, but I don't think it's accurate or fair to say fp 
is in a rut or not progressing.

Nestable calls and large files, mere enhancements though they may be, are 
pretty huge as far as I'm concerned. They are keeping us in the game.
Now you can have truly modular library functions. Ye-ha! I have a whole slew 
of gosubs that can all be gutted out and changed to a line or two code now. 
And the single call table that replaces the multiply copied gosub can now 
benefit from lots of development I was loath to do before. That's huge.

The next mere enhancement to the nested call concept, that will probably be 
hard to impliment and harder to test thouroughly for bad interactions with 
everything else already in fp and all the possible old code... would be user 
functions as was discussed on the list a while back. A function you write 
yourself that can take arguments and return values and be used in-situ like 
any other command/function/expression.

But I don't think fp is treadmilling just because we don't _already_ have 
functions.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!