[fpc-other] Fork

[Adem]

On 2010-10-22 10:04, Florian Klaempfl wrote:
 > Am 22.10.2010 03:21, schrieb Adem:
 >> And, how exactly do you expect them to be proved?
 >
 > Features. Examples why it fixes this or that bug. I didn't see a simple
 > example why splitting the parser into syntactic and semantic parts gives
 > any advantage: the parser in FPC is simply something which works as
 > desired, it has few open bugs (if any at all) and bugs in it are easy to
 > fix.

You don't need me to tell you you're a superlative developer to the 
degree that I won't even claim to be a fraction of. But, often, one 
exceptional talent is granted at the expense of a few others --i.e. none 
of us are as perfect as we'd like to believe we are.

That longish tirade is meant both to appreciate your talents, and offer 
negative criticism at some of (what I consider) short sightedness.

Here is what I mean --and, please help me fill in the blanks I am bound 
to overlook:

How many platforms (OSes and CPU archs) can FPC run on?

My answer is, basically enough --if not more than enough.

IOW, most of the really really hard work is done --not by itself, but by 
you and other members of the core and sometimes by the odd and daring 
<g> contributor.

So.. Where do you go from here?

Focus on unit compilation/loading and/or the register allocator?

Of course, you could do that (and by the looks of it, it already is on 
your mental roadmap too), but are they really --really-- that critical?

I mean, even though having those sorted out would be nice, FPC isn't 
after all crashing without them.

A near-perfect compiler it probably will be.

Now.. let's look at the other option --not that they are mutually 
exclusive, but let's consider them that way for the sake of argument.

Let's suppose that we have agreed that it would be much more fun and 
more useful to turn FPC itself into a kind of component/module which 
itself is composed of components/modules so that people can use FPC as 
an engine for their projects more directly, while other people tinker 
and experiment with modules within the FPC.

At this moment I could offer an analogy from the computer industry, but 
as is customary, I'll stick with the obligatory car analogy as I already 
have.

ATM, at least to me, FPC looks like a custom-made engine and gearbox as 
well as the rest of power train with no user replaceable parts. No 
mortal can dare tinker with it. Can't swap turbos, can't drop in an 
alternative gearbox.

It is, however, a piece of art alright. But, when you consider its 
functional aspect, one invariably wishes to do things with/to it other 
than admire its complexity. And, complex --by George!-- it is. Yet, 
complexity isn't a virtue --sophisticated simplicity is.

I think you should seriously consider not considering FPC as a great big 
black box.