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

[Marcos Douglas B. Santos]

On Sat, Nov 16, 2024 at 1:02 PM Michael Van Canneyt via fpc-pascal
<fpc-pascal at lists.freepascal.org> wrote:
>
> > [...]
> > Don't get me wrong. I've been working with Delphi for over 25 years
> > and with FPC for 6 or 7 years. My career is based on Object Pascal.
> > So, I too am interested in keeping the language relevant... but why
> > follow Delphi? Why does FPC/Lazarus need to maintain this
> > compatibility? Why does FPC/Lazarus need to follow the trends
> > (erroneous, in my opinion) of Delphi or any other language?
>
> Because it means we can reuse code written for Delphi.
>
> Not only components on github/gitlab, but entire projects.
>
> At my current job I'm converting a Delphi application to WebAssembly.
> FPC has (meanwhile very good) support for webassembly.
> Delphi does not have it.
>
> Due to the good compatibility, the same codebase can be used to create a
> desktop/mobile application that runs in the browser.
>
> If we didn't have it, this project would be impossible.

Sure. If we maintain compatibility with Delphi so we can use some
libraries (or even entire projects) and later convert them into
something better, that’s fine—of course, I agree.
My comment was more along the lines of saying we shouldn’t follow
Delphi just for the sake of it. In other words, just because it was
implemented there doesn’t mean we should implement it here, especially
if there’s no actual benefit for us.

> > In my humble opinion, what keeps a language/environment/architecture
> > relevant is how it deals with the world's innovations. It's not about
> > adding new features to the language but adding new layers to address
> > current problems.
>
> That is what I am doing. All my work for FPC is geared towards a single
> goal:
>
> Whatever your project, FPC can do realize it.
>
> Desktop. Server. Browser. Embedded Device: FPC has what you need.

And I believe you will achieve that goal.

But if it’s not at least easy to start a project from scratch using
Lazarus, it will be hard for new developers to see any advantage in
choosing Pascal over another language (one that already provides those
features out of the box).

> > So instead of "wasting time" implementing things Delphi did or what
> > another language did, we could use that time to make everything
> > simpler in the "FPC + Lazarus ecosystem" and forge our own path
> > instead of following "false leaders" who are, in fact, just a slightly
> > larger niche than FPC/Lazarus itself.
>
> I have no idea how big the Delphi community is.
> It's a secret only known to Embarcadero, and they're not talking.
>
> Do you know how big (or small) FPC/Lazarus is ?
>
> I have no idea. I of course hope it is big.

I don’t have official numbers—it’s more of a feeling, based on my own
research—but it’s much easier, for example, to look for jobs in any
other language (like C/C++, Java, .NET, or even Rust) than in Pascal.
On LinkedIn, for instance, you can type "Delphi" (or variations like
"Delphi Developer") and the auto-completion will work. However, if you
try typing "Pascal," you’ll hardly find a position for a "Pascal
Developer"—you might instead get several results for companies with
"Pascal" in their name (the same for "Lazarus").

> > How about:
> >
> > - finally unifying FPC and Lazarus, whether on the FPC website, the
> > Lazarus website, or a new one;
> > using fpcupdeluxe as the official installation method;
> > cross-compilation is very important, and most people using Lazarus for
> > real-world applications use fpcupdeluxe to install Lazarus;
>
> How do you know this ? On what do you base this statement ?
>
> Again, I have no idea.

In every company I’ve worked at that used Lazarus, we always relied on
fpcupdeluxe. In all the groups I’m part of, most people are familiar
with and use fpcupdeluxe. Even new users often report issues with the
official installation, until someone suggests using fpcupdeluxe—and
then everything just works.

> > - having pas2js pre-configured for creating web applications;
>
> What is missing ? It is present in current lazarus ?

I have no idea. In fact, I’m not using the latest version of
Lazarus—my mistake—so some of my ideas might be outdated.

> > - having an option to create mobile applications; we know it's
> > possible (Castle does it), but nobody knows how to do it with a
> > standard Lazarus setup; mobile is current, and we need that!
>
> We're working on improving the support for mobile.

Great news!

> > - simplifying/deleting most of the libraries that are not used by default;
>
> Such as ?

I don’t know. Anything that’s there solely to support 20-year-old
legacy projects but is holding back or hindering the development of
more important priorities.

> > - simplifying the naming conventions of units; using something like
> > "lazarus.blablabla" and "fpc.blablabla" and leaving the main system
> > units with names without prefixes;
>
> No. I think prefixes are actually a good idea.
> Initially, I also didn't like them.
> But I have changed my opinion.
>
> In projects with lots of units (roughly 27.000 in my job project)
> they are actually useful to structure the code.

Sure, it's a good idea.
Even if that breaks some code, it wouldn’t be a big issue to just
rename units—after all, you’ve already done that with the VirtualTrees
unit, renaming it to Laz.VirtualTrees (which wasn’t the best choice),
and you didn’t face many problems, right?

> > - do you want to add new features to the language? Then why not "fix"
> > the WITH statement by adding something like [WITH someobject AS obj
> > DO], so we can use WITH without the problems we all know;
>
> Actually, it has been implemented.
>
> https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/860
>
> It needs some attention, but basically it is ready.

Good to know. I didn't understand why use [with const...] but, Ok, it's a start.

> > - how about allowing the same AS in unit declarations so we can do
> > something like [unit MyUnitWithABigName AS MyUnit] and then use
> > [MyUnit.TSomeClass] — this can already be done with MACROS, so it
> > would be simple to implement in the language, right?
>
> Basically, more syntactic sugar ?
>
> You can do this today.
>
> uses MyUnitWithABigName;
>
> Type
>    TSomeClass = MyUnitWithABigName.TSomeClass;

For a single class, sure. But imagine using many classes, functions, etc.
Also, think about having two (or more) different units with many
functions/classes that share the same name. If the units have long
names with dots, for example, each argument in a method would need to
use the full naming convention (like a.unit.name.very.long.function),
which would be very verbose, don’t you think?

Now, I can do this in FPC (but not Delphi, right?):

uses
  {$macro on}
  FPC.RTL.Windows,
  {$define Win := FPC.RTL.Windows}
  FPC.RTL.Graphics;
  {$define Graph := FPC.RTL.Graphics}
var
  B1: Win.TBitmap;
  B2: Graph.TBitmap;

It works very well.

Now, considerer this:

uses
  FPC.RTL.Windows as Win,
  FPC.RTL.Graphics as Graph;
var
  B1: Win.TBitmap;
  B2: Graph.TBitmap;

So, throughout the unit, you could use Win.Something or Graph.Something.

Much more elegant and still in the spirit of Pascal. Don't you think?

> > Notice that all these new features would NOT break the "philosophy of
> > the language," unlike what has been added over the years.
>
> As most people on the lists know, my concern for the "philosophy of
> the language" is big. I make no secret of it.
>
> But Delphi compatibility is a must-have. If there are things in Delphi we
> don't like, we can implement it, but forbid the use in the FPC code base.
> Such as inline variables - I agree this has no place in well-written pascal
> code.

As I mentioned earlier, if the goal is to maintain compatibility with
Delphi just to use good libraries that were only made for Delphi, then
yes, let's maintain that compatibility! But keep in mind that if the
compatibility is only partial, it won’t be very useful.

Best regards,
Marcos Douglas