[fpc-pascal]The state of FPC (was: Synapse for FPC)

[L D Blake]

In reply to your message of July 24, 2003
> Exactly. For the average joe user, it's single platform work that matters.
> You are focusing as a FPC developer, not an end user. That is why you can't
> see how unwieldy and intimidating the FPC unit structure can be if you don't
> undestand it, or if you come from a Borland background.

Speaking as an FPC "end user" who's only a few weeks into using it on a part
time basis, I have to agree. I've tried looking things up in the source code
folders and it's a real chore. I was used to seeing the Interface parts of
units as contiguous files where you can actually see each procedure (etc.)
listed out ... the FP include files are a nightmare to wade through. I finally
ended up doing some very time consuming in-file string searches trying to find
a simple variable declaration. And after not finding what I wanted, I ended up
writing to a complete stranger asking questions... (Good thing for me he
turned out to be a nice person <G>)


> What I was proposing was that the FPC developers can keep their own scheme,
> but the end users should be presented with readable, single file units. This
> would make everything more accessable to the end user.

Yep.. at least for the Interface parts...

FWIW, my dominant experience is in customer support and about half the calls
my crew used to take were related to unclear or incomplete documentation.
People would say "The help file says '...' What does that mean?" or it would
turn out the information they needed just wasn't there at all. The days when
we used to say "RTFM" in jest are pretty much gone. People do read these
things (i.e. they do read FPC docs and source code). Now the problem is they
either don't understand what it says or can't find the information they went
looking for.  They can't read at our level of technical skill, so we have to
write at theirs.

IMHO... It is very likely FPc's user base is being harmed by it's own file
structure. Re-arrange the unit collection, hide the file used by the file used
by the file that is used by the unit and give us clear Interface documentation
for every unit and it's likely FPC will end up doubling it's user base in very
short order.

The first step is to simplify and rationalize the file structure... Start from
your base PPC directory, branch to targets, then to units,bin,lib, then to
sources and docs for each second level branch.  I rearranged my copy of FP
like this:

                h:\frepas\win32\bin
                h:\frepas\win32\bin\source
                h:\frepas\win32\units
                h:\frepas\win32\units
                h:\frepas\win32\units\fcl
                h:\frepas\win32\units\fcl\source
                ...
                h:\frepas\go32\bin
                h:\frepas\go32\bin\source
                ...

and it's a LOT easier to find stuff in there now. Mind you, I doubt I could
compile it from that without a LOT of fuss and trouble but it's also unlikely
I would ever need to re-compile it. At least I can now find information when I
need it.

Where you must include depenencies in a distribution the file structure
should reflect that, as in:

                \ppc\%target%\units\fcl
                \ppc\%target%\units\fcl\uses

Where only the main ow and ppw files for FCL are in the fcl folder. The rest,
the ones used by the main units, should be in the "uses" directory where we
don't need to worry about them.
                
A concise Interface declaration should also be present for each file we can
directly list in our Uses clause. I'm used to seeing something like "sdos.tpu"
accompanied by "sdos.txt" listing the interface declaration and, where necessary,
any special instructions the unit requires.

It might also be a lot clearer for the end user (i.e. me) if you moved the DOC
directory over to:

                \ppc\%target%\units\fcl\doc

Same with the sources:

                \ppc\%target%\units\fcl\source
                
At least then we could easily associate the information with the files it's
describing.

Also... do you realize that *noplace* in your documentation do you tell us
which files to list in our USES clauses for each unit?


Thing is, FPC is a great little compiler... I didn't choose FPC because it's
free. I have 2 different versions of Delpi and a copy of C++ within arm's
reach... I don't need to use free compilers. I chose it because it's the best
for what I want to do.

Reason 1... I have a small DOS program that loads up, renames about 10,000
files I have in a clip art collection and then exits. I just re-wrote it for
windows In D7 it's about 380k, in FP it's under 40k.

Reason 2... To give a copy of a Delphi program to a friend I may also have to
give out one or more DLLs. FP creates standalone EXEs.

Reason 3... Doing a simple test of a "count to a zillion" program Delphi
takes much longer than FP.

Reason 4... I am not using "Object Oriented Programming".  I'm an old school,
brute force, programmer.  Delphi gives me no choice.  FP lets me do as I wish.

Reason 5... Delphi's IDE hides a lot of stuff from me.  Using the visual
designer in D7 I never see the RES files or the Source Code until I am writing
method handlers.  In FP I have complete control over every last character of
my work.

But, even with such compelling reasons, I almost trashed FP a dozen times; not
because of the way it works or because it has limitations... Being someone's
part-time project, I expected to run into crashes and things I just couldn't
do, but that hasn't happened yet. Frankly it's the documentation and the
"scrambled eggs" file structure that was giving me fits. I'm in a learning
curve here... I need information and I need it in a concise and readable way.

It really isn't enough to just zip up the developement directories and send
them out... WE don't know what the developer did or why they did it... we just
want to use the package... because it's a great little compiler.


>> > Remeber, just because it's easy to maintain for you, doesn't mean it's a
>> > good thing for the end user. That's a fact I'm afraid.
>>
>> Once more, this is a matter of taste.

> No, it's not. This is a matter of fact. It's also a matter of fact that many
> developers focus on their own back yard, and don't bnecessarily see the
> bigger picture. The end user is often ignored or worse still told they are
> wrong. Kind of like now really ;-)

Ummm... very simply... End users aren't mind readers.

In this case, presentation of information is at least as important as the
quality of the software.

-----
 L D Blake