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
<fpc-pascal@lists.freepascal.org> 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  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to