[fpc-pascal] Fwd: What to do to get new users

[Michael Van Canneyt]

On Thu, 17 Oct 2024, Sven Barth via fpc-pascal wrote:

> Michael Van Canneyt via fpc-pascal <fpc-pascal at lists.freepascal.org>
> schrieb am Do., 17. Okt. 2024, 11:40:
>
>>
>>
>> On Wed, 16 Oct 2024, Hairy Pixels via fpc-pascal wrote:
>>
>>> On Oct 17, 2024 at 12:03:47 AM, Guillermo Martínez Jiménez via
>> fpc-pascal <
>>> fpc-pascal at lists.freepascal.org> wrote:
>>>
>>>> Prease DON'T add garbage collector.  IMO it isn't a good idea.  I had
>>>> very bad experiences with it. Unless somebody found a new magic
>>>> algorithm in the last decade...
>>>>
>>>
>>> I used C# for Unity quite a bit and never had any problems. That’s even
>>> with the worst case scenario for game developing that needs real time
>>> graphics. Does that power all of .NET too and all those desktop
>>> applications? It’s been battle tested many years as far as I can tell.
>>>
>>> In 2024 you don’t need the performance of manual memory management in UI
>>> apps. Garbage collector or anything else will work perfectly well.
>>
>> I don't write UI apps, only server apps.
>> Performance matters there, so a GC is not good.
>> We see this at times in our servers, when the GC kicks in; everything just
>> stops.
>>
>> In each case, it is a bad idea to slap this on an existing language:
>>
>> a GC collected language is a complete paradigm shift from non-GC.
>> C# and Java (and probably others) were designed with GC in mind.
>> That it works there is therefore not surprising.
>>
>> By contrast, Pascal is not designed with GC in mind.
>> You'd need to redesign the language.
>>
>> If you do that, you can throw away all existing code if you introduce GC,
>> because the two concepts do not merge easily.
>>
>> Embarcadero tried it in Delphi, and they failed. Not surprisingly,
>> they removed again all automatic memory management.
>>
>
> Probably something like the std::*_ptr (shared, unique, auto, etc.) from
> C++ could be implemented in FPC. Main point missing for a convenient
> solution would be a mechanism so that e.g. classes could be accessed as is
> from such types (for example default fields)
> A proof of concept implementation should be doable without that however.

I have one provided by a colleague that is a C++ jedi... I planned to put it
in types.pp, since the implementation is ridiculously small and depends on
nothing.

Michael.