[Lazarus] Rescan FPC sources crashes Lazarus

Marco van de Voort marcov at stack.nl
Sat Mar 26 15:22:31 CET 2011


On Sat, Mar 26, 2011 at 11:12:18AM +0200, Graeme Geldenhuys wrote:
> > You know the answer, Graeme...
> >
> > But I agree that this could be done better. Keep the IsMultiThread variable
> > for Delphi compatibility,
> 
> And if Delphi jumps off a cliff so will all FPC developers?  Well, I will
> NOT.

Answering from the same experience as with TP's death:

We will probably jump of the cliff, and climb back on 5-8 years later. By
then most Delphi code will be dead or maintenance only, and compatibility
will be less important.
 
> While we can't help for the Delphi developers being stupid, we could
> try and learn from their mistakes and make FPC better! I'm pretty sure
> many here would agree, that we all choose to use FPC with the hopes
> that it is BETTER than Delphi, not just a damn second rated clone
> (always being one step behind Delphi).

The trouble is that you always tend to focus on the tiniest little detail
that you ran into the last 10 minutes, and then try to make that the center
of the FPC universe, as if it were a leaking nuclear reactor. Everything is
a balance.

While in reality it is more the missing of a ribbon or foil around a
matchbox that avoids the matchbox opening accidentally (*)

(*) Do you see matchboxes with ribbons in reality? No, because not all
theoretical holes are plugged because that it 

> There are many new designs and improved programming styles or design
> patterns that reduce (or totally eliminate) the need for such unsafe
> global variable usage.

Since when is information hiding and access control new? It's eighties
technology.

Keep in mind that design patterns are not new. They go back to 1996, and
even then they only claimed to standarize practices already in use for
decades.




More information about the Lazarus mailing list