Re: What to do to get new users

On Sat, 16 Nov 2024, Marcos Douglas B. Santos via fpc-pascal wrote:

> On Sat, Nov 16, 2024 at 11:43 AM Michael Van Canneyt via fpc-pascal
> <[email protected]> wrote:
>>
>> > I could see that if it was a compiler for “Pascal” which was defined by
>> > some other group and you could reference them but it isn’t. FPC is a
>> > language in its own right and the compiler is the only place that
>> > implements it.
>>
>> Really ?
>>
>> You never heard of Delphi, ElevateWeb, Smart Mobile Studio, PascalScript, OxyGene ?
>> There are some others, can't recall the name. There is a Russian version,
>> called abcpascal or something similar.
>>
>> They all implement "object pascal", as defined by Delphi.
>
> This is something I don't understand. Why should all these
> environments and we, as Free Pascal/Lazarus users, follow Delphi's
> standards?
>
> 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.

> Object Pascal is, in my opinion, one of the best programming languages
> ever created—if not the best. It is easy to understand and write; you
> can implement anything with it, from an operating system to visual
> applications for end-users.

No argument.

> Its structural organization is one of the
> things that sets it apart from other languages, where everything has
> its proper place to be declared... well, that used to be the case.
> Now, variables can be declared "anywhere"; "anonymous procedures" now
> exist and can also be declared "anywhere"; we have Generics because,
> well, Delphi and other languages have them, so we must have them too,
> right?

Depending on your goals, yes.

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

>
> Let me explain: think about all these new features that have been
> added to the language and tell me what (most of them) allow us to
> build now that we couldn't build before. Most people still use the
> language to create the same kinds of systems. Does that make the
> language obsolete? Not if it can still create systems that are usable
> today! If it has performance, is easy to write, and is maintainable...

I agree.

I don't use these new features, or only very sporadically.

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

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

> - having pas2js pre-configured for creating web applications;

What is missing ? It is present in current lazarus ?

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

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

Such as ?

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

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

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

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

Michael.

_______________________________________________
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal