Sorting an array

[Jose Lerebours]

Point taken ... Understood!

Yes, I totally missed it on your first post.  ;-)

But really, use of "user" or "system" to call an external process in 
filePro is hardly a "Gorilla".  Using "chain", "call" or anything else 
in any reasonably sized filePro application is a daily thing.

I used to worry a lot about "speed" and "memory" and one of my colleges 
kept reminding me that PCs or Servers now run with 64GB RAM and several 
Ts of HD space and Quad processors at speeds we could only dream of back 
in the 80s.

So, adopting PHP or Perl or Python as a "cousin" to a filePro 
application is not as crazy given the added benefits and the relatively 
small (hardly measurable) footprint in processing time. A PHP script can 
sort a multilevel array with over 10,000 rows in a blink of an eye.

If only I had a $1 for every time a customer said "that is all I need 
..." and ended up changing shortly there after.  Meaning, saying "20" 
elements does not mean necessarily it will never be more than that or 
that there will never be a need to sort an array bigger than that in a 
different area of the application.

Any way, solutions are many, options are many, opinions are even more 
... I like to think permanent solution and not "patch" to get you out of 
my way! sort of approach.

Thanks for clarifying the "suggestion" of use of "bubble sort" ... I 
really had not heard of it since College.  ;-)



On 05/18/2016 09:03 PM, Fairlight via Filepro-list wrote:
>> Go ahead, use Basic for this task and hope you can use it for your
>> next task, and the next one, and the next one ...
>>
> [...]
>    
> You appear to have -completely- missed my point.  I was -not- saying I
> advocated using BASIC for the task.  I was saying that the required bubble
> sort can be done in a language as dated and (typically inadequate) as
> BASIC, so it's therefore easily implementable -inside filePro-, without
> needing to using -any- external language.
>
> Why would anyone invoke the 500lb gorilla overhead of PHP, when you can
> bang out a pure-fP bubble sort?  That's nuts.
>
>> As I said, "I prefer PHP", did not suggest it was the "best nor
>> only" solution.  Over Basic, I still choose PHP.  If I am not
>> mistaken, you may be able to install it, run it as "scripts" and not
>> have to install Apache nor MySQL if resource is an issue.  Sorting
>> array in PHP is as simple as:
> [...]
>
> I prefer not to use more system resources than necessary.  Every time you
> invoke -your- solution, assuming you're using SYSTEM, you're invoking:
>
>       1) One bash shell for parsing SYSTEM's command, before you even call
>       2) One php interpreter, both of which use
>       3) Way more RAM than necessary for this simple task.
>
> Frankly, it's sloppy and massive overkill.  If we were parsing XML with
> all its vagaries and complications, I'd buy it.  We're not.  We're talking
> about a simple sort algorithm which has been around for decades.
>
>> Do not be ashamed if you have to resort to dumping data to a filePro file
>> and read it back, you do what you must to get the job done.
> And "must" is absolutely a misnomer in relation to bringing in external
> tools for doing a bubble sort which can be done directly inside filePro.
>
>> This is quick and easy within your environment.  It is a common
>> practice to create temporary tables to store, manipulate data and
>> doing so in filePro should not be cause of shame.  In SQL, one
> It should be cause for shame if the task is easy enough that you're
> draining far more system resources than necessary for the task at hand.
>
> "Quick and easy" is -not- always the correct solution, and the path of
> least resistance often comes with a price to be paid later.
>
> There's a reason that the best programmers have actually learned -systems-
> to a decent degree, as opposed to taking the stance of, "I just program in
> [insert_language].  I don't need to know systems, nor do I care to."
> Software doesn't exist in a vacuum; it runs -on- systems.  Yes, if you're
> programming, you should know the OS, and you should know (or at least
> research) the expense you're invoking by taking any given path, -before-
> you decide upon a path.
>
> There's a reason PHP coders are a dime a dozen, and often suck beyond
> the telling of it.  They quite often -don't- usually know systems, and
> therefore write insecure, bloated, horribly convoluted code which nobody
> in their right mind would touch if they had a clue.  PHP is the AOL of
> languages: so simple, any idiot can do it Ä and far too many do.  PHP and
> especially PHP web applications are a blight upon security, largely because
> the people coding both seem not to know or care about the underlying
> systems which support their code, and don't bother to learn in most cases.
>
> I'm not saying there are no good PHP programmers.  I know some exceptional
> ones.  But they -are- in the minority, IMNSHO.
>
> And more to the point at hand, NO external program is necessary in the
> proposed case, in the first place.
>
>> Then again, some one like J.P. or Barry (??) White may point you to
> Brian White.
>
> mark->