>>>I agree with all you are saying. But when I put the code in PRG without declaring the FUNCTION, it feels very 90s :)
>
>So what? Actually, the point where it became possible to call a function by filename is probably in the 80s, which doesn't exactly diminish its ingenuity.
>
>>I disagree. The people who started arbitrarily collecting stuff into prgs did so to get around the 8.3 filename limit. At the time, that only gave an 11 char uniqueness. That was done in the 80s if I remember.
>
>Also done a lot by guys who did Clipper first (me included). You were pretty much told that's the way to do it, and I guess the practical value was to save time maintaining the file list to submit to linker - I think proper project manager didn't exist in Clipper and not in Fox for that matter, until FP2.0.
>
>Actually finding things in project manager is the only reason against having each thing in its own prg, because it would clutter the pjx.

The project manager isn't the best tool for productively managing the parts of an application. The toolbox is better.

>On the last few projects I did the number of free-floating functions was reduced drastically by grouping them into objects (by purpose), which are then instantiated as singletons - but the function calls are still in too many places in code, so there's usually one big prg with just stubs - something like
>
>function GetAppRootPath()
>return app.oPaths.approot
>
>So instead of having getAppRootPath.prg, getAppLaunchPath.prg, getUserDocsPath.prg, getTempPath.prg, etc, there is just libPaths.prg, etc etc. The remainder are the few dozen functions which didn't have a natural global object which would host them.

We're not supposed to have god or global objects. I think you meant a natural object to host them. I do make things methods when appropriate. Bear in mind the performance hit added by making these fundamental functions into objects.