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

[Sven Barth]

Michael Van Canneyt <michael at freepascal.org> schrieb am Do., 17. Okt. 2024,
14:37:

>
>
> 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.
>

Does it have tests as well? Otherwise that sounds good 😁

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20241017/9e9a489e/attachment.htm>