What should fp 6.0 look like?

[Fairlight]

Yo, homey, in case you don' be listenin', Patowic done said:
> 
> What I wouldn't give for the ability to suck data out, efficiently, with 
> either Perl or Python.  It would make me like FP a _lot_ more, because 
> then I could use two languages I understand, rather than having to learn 
> the language that is FP's 4GL.  Like all 4GLs, I find it artificially 
> limiting, and arcane.

God, you sound like me a few years back.  I've come to accept fP's
language, though I too share your feelings on limitations imposed when
compared to other languages.  I guess you have to (and I have, to a point)
look at it from the standpoint of their having traded higher-level
structure for RAD speed.  Most of the fP users wouldn't at all be
comfortable in perl or phython.  There are definite exceptions--some are
good friends and/or clients.  But by and large, they're happy with their
language, and therefore it's not going to change substantially from a
syntactic point of view any time soon.  They will, however, likely add
functions as needed.

Best bet for you here is wait until fP-API comes out, and pray it supports
perl.  That would make your life simpler.

> > And I've looked...there doesn't appear to be a terminal-based RAD kit for
> > any of the *SQL engines.  You've got several GUI solutions, some web-based
> > solutions, but no terminal-based solutions.  If fP just went the route
> > above, they could hit a really nice market segment, since there's a virtual
> > vacuum in this area.  If they'd let go of some of the legacy issues and
> > enhance things a bit (like allowing > 80x24 screens), this could be sweet.
> 
> I'd buy in a second.  This would allow me to genuinely leverage the data 
> in FP, and my previous investment.  Instead, I find myself using editors 
> which are not as familiar to me as vi, a language that I'm still 
> learning, and a whole new set of language-limitations (since pretty much 
> all languages use them).

See, it's things like seeing that people would snap it up that TPTB need to
see to make it a viable development/investment direction.  Glad you spoke
up.

As for the editors, etc...you -can- use vi, you know.  At least for
processing.  Set ABE=ASCII in your environment, resave the table from
dcabe, and then just vi the prc files at will.  Someone taught me that you
can even syntax check them without going into dcabe fully:

     dcabe table myprocessing -c

> > Kill 80x24 screen limits.
> 
> PLEEEEEEEEEEEEEEEEEEEEEEEEEEEASE.
> I'm getting to the point where I'm out of acreage on a single screen.
> The information is all related, and it would be easiest to display it 
> all in one place, but I will no longer be able to do this, since I'm 
> simply out of room.

Well, until they do, my old solution was to go multi-screen and use the
screen() command to jump at the point they'd hit save, and just track what
screen you're on.

> And the ability to natively export csv.   MAN, would that save me some 
> coding.

Someone around here (Alan Mazuti) has a program written in perl that will
let you write complete .xls files.  I can't remember what the import format
for it was, but I know it was being used with filePro.  You might talk to
him about it, if you're interested.  He may be able to work something out.
It's not native, but it was slick.

Contact:   Alan Mazuti <amazu at trusteeservicesinc.com>

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html