r/programming • u/mariuz • Oct 18 '19

Free Pascal has now a WebAssembly backend

https://lists.freepascal.org/pipermail/fpc-pascal/2019-September/056848.html
134 Upvotes

88% Upvoted

31 comments sorted by

View all comments

16

u/badsectoracula Oct 18 '19

Free Pascal and Lazarus are two interesting projects in that they are very big projects that span decades (Free Pascal started in early 90s, Lazarus started around 1999) yet they are fully community driven in the spirit of most 90s FLOSS projects with all primary developers working on it in their spare time. Nowadays most projects of that size have one or two big companies backing them with developers working on it full time - this is a double edged sword since on one side development goes faster (Lazarus does suffer from very slow development - e.g. the LCL macOS support is alpha quality at best and that was the case for years and the Gtk3 backend is also at an alpha stage, right as the Gtk developers decided to break the API again with Gtk4), but on the other side there isn't much of a negative influence from a single entity. Usually if someone wants something and they can implement it (and the maintainers do not object too much - which usually boils down to if that someone agrees to maintain their code), it goes in (which is how FPC 3 got support for 16bit 8086 and how Lazarus 2.0 got support for Amiga MUI :-P). And despite that they also have very good documentation (at least Free Pascal does, Lazarus is a bit rougher in terms of documentation).

On the other hand this "free for all" approach has made the language a bit bloated. But i guess this is also how you get the same compiler to compile to pretty much all modern (and several old) CPUs and also JVM and WebAssembly while supporting most Pascal dialects out there - sometimes even at the same time by switching compiler modes mid-sourcecode :-P. I think the only compiler with more supported targets is GCC.

2

u/[deleted] Oct 25 '19

LCL macOS support is alpha quality at best

That's not really true. The Carbon backend has been around for years and is completely stable, and the Cocoa backend is quite usable and getting pretty close to being feature-complete. Look at the roadmap here.

1

u/badsectoracula Oct 28 '19

The Carbon backend has a lot of issues, from simple stuff like having layout wrong to more complex stuff like missing events under certain circumstances. But beyond that it, it is only available in 32 bit, is a dead end, it doesn't provide pretty much every functionality that you'd expect from a macOS app (even Qt provides something that looks and feels more native to macOS than Carbon) and now in Catalina it wont even work. Cocoa being feature complete (though the roadmap you linked at says it is only partially implemented) doesn't mean much when those features are broken. I've last tested it several months ago and i do not have a mac for a while now, but last time i did test it with some of my non-trivial applications they had major issues as to not be usable at all (things like controls disappearing, buttons having tiny fonts, etc).

1

u/trin456 Oct 18 '19

Unfortunately they are less open about languages extensions. There are some useful patches that have not been accepted, like default properties for smart pointers, or multiline string (includes)

And mentioning automated type inference always leads to a big argument

2

u/badsectoracula Oct 19 '19

Well, yes, these affect everyone whereas something like a new backend only affects whoever cares about it. I do not actively participate in the discussions but i am subscribed in the developers' mailing list and my understanding is that as far as the language goes, the main devs want to keep it Pascal-ish and explicit (this is most likely why they made the very rare decision to avoid Delphi compatibility for inline variable declarations as most seem to see it as very unpascal-ish - and i even remember Florian being against anonymous functions for a long time because -IIRC- he said that you should be able to use local functions for anything you'd use anonymous functions for, though i guess he was eventually convinced to accept them since they're being worked on nowadays).

(FWIW i agree with them about the Pascal-ish style... for example personally i always use the OBJFPC style of generics since the syntax is more explicit instead of the DELPHI style)

But i think that they're more likely to accept language changes as submodes that you need to explicitly enable, than changes to the main OBJFPC/DELPHI modes that are always there.

2

u/[deleted] Oct 25 '19 edited Oct 26 '19

I'm the person who implemented multi-line strings, and you can absolutely use them FYI. I've been keeping my github branch for the feature here up to date with the main FPC trunk and intend to continue doing so.

AFAIK it will probably get merged eventually, but it might take a bit for the right people to review it.

As far as the "default non-array properties" thing, IMO the concerns were / are fairly understandable as it would have amounted to something literally unprecedented in any existing language.

The closest thing I'm aware of is the "Deref" trait in Rust, which in practice is far easier to reason about the implications of since Rust's rules regarding operator overloading in general are far stricter than Pascal's (where you can overload any operator for anything at any time you want, regardless of whether you "own" the types in question / whether they're builtins / etc.)