Initially, I was skeptical and thought that this is the millionth vibe-coded project that will die once the author gets bored.
However, when I checked who the author is, I found he is is Graeme Geldenhuys, the author of the fpGUI library [1]. He surely has a lot of experience with FreePascal and the Pascal language, and in these years he has proven to be a committed worker (fpGUI exists since 2010!). So, this project seems to start on good grounds!
I really hope it will gain traction, as I have often wondered myself why somebody would not create a “clean” Pascal compiler from scratch with no legacy cruft and good defaults (e.g., UTF-8 strings, inline variable declaration).
Which has had a strange relationship with Delphi, for a while they were responsible for Delphi.NET.
samuell 1 days ago [-]
It is a bit curious with the Mojo 1.0 beta coincidence, as Pascal was the other langauge with a highly readable and quite simple language combined with performant compiled code without GC.
What it lacked was a modern compiler and stack. There is FreePascal for sure, and Lazarus is impressive, but it for sure has its baggage.
vintagedave 1 days ago [-]
Yeah, Python and Pascal have always felt like they share similar vibes, despite being massively different languages. (Ease of writing, ease of reading, good inbuilts, etc.) Mojo feels like a clean take on similar goals... it's essentially a cleaner Python.
jibal 23 hours ago [-]
Mojo is faster than Python but certainly not cleaner.
vintagedave 23 hours ago [-]
Can you share more? I haven't actually used Mojo, I've just read about it, so I'm going on vibes (not AI ones :D) here. I'd love to hear your opinion.
jibal 18 hours ago [-]
Mojo has both Python's def and its own fn -- two different flavors of functions. That alone isn't "cleaner". fn is there for high performance -- it's like Rust added to Python. Mojo is still missing Python functionality because it's early in development, so by that measure it's also not a "cleaner Python" ... and the parts that will never be added are because of performance, not cleanliness. Mojo has never been advertised as a cleaner Python so I don't know what vibes you're going on.
Looks interesting. As someone who's been using Pascal since Turbo Pascal 6, and use Delphi daily at work, I'm not sure I quite get the "COM-style interface GUID" objection. What exactly about it is complex, and how do you implement Supports() without it?
graemeg 22 hours ago [-]
It's magic! ;-)
Not wanting to go into too much technical details: Blaise's interface system uses TypeInfo pointers as identity tokens. Meaning manually added GUIDs are not needed.
The two Supports() forms. Delphi has two overloads:
// 1. Boolean test
function Supports(AObject: TObject; const IID: TGUID): Boolean;
// 2. Combined test + assignment (the useful one)
function Supports(AObject: TObject; const IID: TGUID; out Intf): Boolean;
In Blaise, without GUIDs, the second argument is an interface type identifier rather than a GUID. The most natural design is to treat Supports as a compiler intrinsic (like is/as) rather than a library function, because the second argument isn't a runtime value — it names a type.
So Blaise code looks like this:
if Supports(Obj, IFoo) then ... // boolean test
if Supports(Obj, IFoo, FooRef) then ... // test + assign fat pointer
magicalhippo 22 hours ago [-]
Ok, so not unlike the RTTI helpers in Delphi then.
Consuming a precompiled binary like a third-party DLL is out of scope then presumably, since TypeInfo pointers won't match.
Which is fair enough, it's not that common these days beyond actual COM usage.
But still not sure exactly why no GUID is a selling point. It's just a bit of metadata.
vintagedave 1 days ago [-]
Not the OP, but I can answer with an objection to COM-style GUIDs myself. Delphi's interfaces are heavily based around COM, and so you need GUIDs, ARC, etc.
But interfaces as a concept don't require the COM backend. If you want your code to be cleanly separated, but don't want to split ownership/management models* (create/free vs ARC), and have no need for an interface and type identity to be managed outside your code and process (ie no COM), then interfaces that are not tied to ARC, and not tied to COM, give the clean code benefit without the baggage.
[*] People work around this by implementing interfaces from a base class with no-op AddRef/Release methods. But this kinda shows the problem: why is that necessary?
I work with Oxygene which is another modern Pascal -- quite a few new Pascals have popped up recently, I get the sense there's a real desire for something new! Our interfaces can be 'clean' and we support soft interfaces, too.
magicalhippo 1 days ago [-]
But you don't need to specify a GUID for an interface in Delphi, and Blaise uses ARC for both objects and interfaces.
vintagedave 1 days ago [-]
True! But here at least Blaise is consistent. It’s not mixing models.
My real wish for Pascal interfaces is that they are pure. Some of that is not bringing in COM stuff (including recounting) because I think memory management is or should be different to interface-based clean coding. Another: In Delphi if you define a property in an interface, you have to bring in the getter and setter too. And that makes them implicitly public / visible (even if the implementing class declares them as private.) And they must be methods, there’s no way to say “read, but I don’t care how” (where Delphi can normally read fields too.) In other words, the semantic of “I want a property with read access” causes the interface contract to define the implementation, including making public the normally private / internal backing.
Whereas what I really want is to declare “property Foo: Integer read;” and the interface requires that is satisfied, but not how. In other words, interfaces are pure - they don’t bring in extra baggage. You can do that in Oxygene.
magicalhippo 1 days ago [-]
Being restricted to COM-style interfaces, so no true properties like you say, that I totally get.
However my question was mostly with the objection against having a GUID, and how Supports() is solved without said GUID, especially since Delphi interfaces doesn't require a GUID in the first place.
vintagedave 1 days ago [-]
I guess the language implementer needs to answer how they implement Supports :)
But within one app, ie not crossing boundaries, perhaps their object model's vtable carries references to the interfaces, so casting of any sort to/from object-interface and interface-to-interface would work, including Supports?
graemeg 22 hours ago [-]
And FPC also supports interfaces without GUIDs via the {$interfaces CORBA} directive, and it too, supports the Supports(...) construct just fine.
Delphi is just very Windows-centric with a lot of things they do.
jasim 1 days ago [-]
In my early programming days, working with Clipper, I used to look at Delphi from a distance with awe and a bit of jealousy. There also used to be PowerBuilder and Paradox, as competition to the xBase platforms.
I'd love to hear more about how you're using Delphi and what it excels at, compared to current web and native software stacks.
rob74 23 hours ago [-]
Not the parent commenter, but what Delphi always excelled at was being able to quickly click together a GUI (with a WYSIWYG UI designer) and easily hook up the events (onClick etc.) to your code. That, and the blazing fast compilation speed which contributed to making quick iteration easy. Think VB6, just with a "serious" compiled language sitting behind it. Current versions of Delphi also support MacOS, iOS, Android and Linux (?), although I'm not sure how well that works, as I got off the Delphi train back in 2010.
cestith 20 hours ago [-]
FreePascal and Lazarus certainly support Linux fully, if there are any deficiencies in Delphi’s support.
magicalhippo 23 hours ago [-]
To be fair, Delphi was left to rot during a crucial point in time, around when .Net was being created. It has struggled ever since due to that.
And while the attention to backwards compatibility has been astounding, the move to Unicode-by-default strings was a non-issue for most unlike say Python, the language suffers and feels a bit tedious at times compared to say modern C#.
That said, for creating Win32 applications, especially CRUD stuff, there's nothing quite like it in terms of the efficiency of getting deliverables to customers.
dvh 1 days ago [-]
For me the only reason to use pascal is GUI apps but this doesn't have it.
ptrott2017 21 hours ago [-]
You can use Lazarus from a C interface - via liblcl. There are bindings for Go and Nim that use this method. Given the QBE backend, this may be one possible route for Blaise but needs investigation.
graemep 23 hours ago [-]
I have not used Pascal, but things that appeal to me (other than GUI apps) are that it seems simple to learn, and is readable, fast and compiles fast.
What languages would be better in these ways?
crq-yml 14 hours ago [-]
Forth could make a case for "faster" in compilation, at least, since it's aggressively machine-level(in a traditional assembly-up bootstrapped system) but blends a mix of interpreted and compiled. Readable and fast in the real-world cases, OTOH, is a matter of taste and engineering practice. I'm doing hobby Forth and it's a blast - it starts off as a crude load-and-store Fortran-like language, and gradually evolves as you stumble into new idioms. If I had to work with a team, I would probably yearn for a Pascal where some bureaucratic boundaries exist on what can be done.
graemep 9 minutes ago [-]
Thanks, that sounds interesting. I learned a tiny bit for Forth for fun a long time ago but no one else seems to use it and it does not seem to have much of an ecosystem so it looks like its only for niche hobby projects? What sort of projects do you use it for?
Excited to see another project targeting the QBE back end, from what I can tell it's a great lightweight alternative to LLVM.
graemeg 22 hours ago [-]
Yes it has been fantastic to work with QBE so far. It's way simpler than LLVM, giving you about 70% of the LLVM performance, for 10% of the effort. :)
Only downside is Windows support.
paddim8 18 hours ago [-]
Unfortunately the QBE code is really strange so if you need to make some changes yourself it probably won't be very fun
crq-yml 14 hours ago [-]
I'm actually really happy to see a fresh "just Pascal", and one that is aiming for a slim bootstrap at that.
mark_l_watson 22 hours ago [-]
That looks cool. If they support binary releases on macOS Apple Silicon I will try it out.
I wrote one major project in UCSD Pascal on Apple II 45 years ago: my Honnibo Warrior Go Playing program. For its time, a fantastic dev environment.
superdisk 1 days ago [-]
Looks cool and does aim to address some of the annoying warts in Pascal. Especially the memory model.
HexDecOctBin 1 days ago [-]
Does this support declaring variables anywhere (as opposed to only in the beginning of a function)? That was my primary complaint when using Lazarus.
pjmlp 1 days ago [-]
Delphi has allowed this for quite some time.
vintagedave 1 days ago [-]
Yes - OP, you can do this via inline vars and consts:
begin
var foo : string := 'hello';
const c : integer = 5;
var bar := GetBar(); // type inference even
// and in blocks:
for var i := low(x) to high(x) do...
end;
HexDecOctBin 24 hours ago [-]
Yeah, but then I'll have to deal with Embarcadero.
tomekw 1 days ago [-]
That’s so great! Thank you!
I wish something like this existed for Ada :)
anthk 22 hours ago [-]
Will you port it to 32 bit? There's already a QBE port for it.
Ok, there's no way to bootstrap it without FPC... can the compiler compile itself?
graemeg 22 hours ago [-]
Every new compiler needs to be bootstrapped by something - unless you head straight into Assembly Language from day1 - but I'm not that crazy!
Yes, Blaise reached self-hosting after just 7 days. Meaning it could compile itself, and was byte-for-byte identical to the bootstrapped version. The language was absolutely barebones, but that's not the goal at that stage. The first (FPC) compiled binary is called the Stage 1 binary. That binary then compiles the compiler code to make a Stage 2 binary (a read Blaise compiler binary). Then Stage 2 compiles the compiler code again to make a Stage 3 binary. Self-hosting is when the stage-2 binary and stage-3 binaries are byte-for-byte identical. Blaise has already achieved that.
I'm currently actively working on removing the FPC and GCC bootstrap requirements. After which Blaise would become it's own bootstrap compiler.
zx8080 1 days ago [-]
Sorry, I don't trust a compiler project that's done in 3 weeks (I've checked the repo commits history). Downvote this if you want.
1 days ago [-]
skeeter2020 21 hours ago [-]
is this done? from what I read it's not really (i.e. community) started. Go a bit deeper than the commit history and look at the person behind the project. As we enter the AI developer winter the personal reputation of the author is going to become incredibly critical IMO.
zx8080 13 hours ago [-]
There's no any ai winter on the horizon. Yet.
cestith 18 hours ago [-]
It’s fair not to trust it yet. It’s pretty clearly a work in progress. I think the point right now is to raise awareness of the project so it can be watched by and perhaps obtain contributions from more people.
Valid concern which should not be downvoted. For some this will be too early to garner interest or confidence. For others, especially those interested in the Pascal language family or building a compiled language with QBE, there is a lot of things in this project that justify taking a close look. (Not least of all, Graeme's proven track record in the Pascal community). Glad the project is getting some deserved attention and looking forward to seeing how it evolves.
satnhak 21 hours ago [-]
That's exactly what I was thinking.
graemeg 22 hours ago [-]
Every new project starts at Day 1. :-)
1 days ago [-]
lpcvoid 1 days ago [-]
From somebody that used to live in the Delphi world for about a decade: very nice!
peter_d_sherman 1 days ago [-]
[dead]
Rendered at 11:54:52 GMT+0000 (Coordinated Universal Time) with Vercel.
However, when I checked who the author is, I found he is is Graeme Geldenhuys, the author of the fpGUI library [1]. He surely has a lot of experience with FreePascal and the Pascal language, and in these years he has proven to be a committed worker (fpGUI exists since 2010!). So, this project seems to start on good grounds!
I really hope it will gain traction, as I have often wondered myself why somebody would not create a “clean” Pascal compiler from scratch with no legacy cruft and good defaults (e.g., UTF-8 strings, inline variable declaration).
[1]: https://fpgui.sourceforge.net/
This part isn’t true, for many years now we’ve also had Oxygene - https://www.remobjects.com/elements/oxygene/ (also proprietary)
What it lacked was a modern compiler and stack. There is FreePascal for sure, and Lazarus is impressive, but it for sure has its baggage.
This might be helpful: https://mojolang.org/docs/manual/python-to-mojo/
Not wanting to go into too much technical details: Blaise's interface system uses TypeInfo pointers as identity tokens. Meaning manually added GUIDs are not needed.
The two Supports() forms. Delphi has two overloads:
// 1. Boolean test function Supports(AObject: TObject; const IID: TGUID): Boolean;
// 2. Combined test + assignment (the useful one) function Supports(AObject: TObject; const IID: TGUID; out Intf): Boolean;
In Blaise, without GUIDs, the second argument is an interface type identifier rather than a GUID. The most natural design is to treat Supports as a compiler intrinsic (like is/as) rather than a library function, because the second argument isn't a runtime value — it names a type.
So Blaise code looks like this:
if Supports(Obj, IFoo) then ... // boolean test if Supports(Obj, IFoo, FooRef) then ... // test + assign fat pointer
Consuming a precompiled binary like a third-party DLL is out of scope then presumably, since TypeInfo pointers won't match.
Which is fair enough, it's not that common these days beyond actual COM usage.
But still not sure exactly why no GUID is a selling point. It's just a bit of metadata.
But interfaces as a concept don't require the COM backend. If you want your code to be cleanly separated, but don't want to split ownership/management models* (create/free vs ARC), and have no need for an interface and type identity to be managed outside your code and process (ie no COM), then interfaces that are not tied to ARC, and not tied to COM, give the clean code benefit without the baggage.
[*] People work around this by implementing interfaces from a base class with no-op AddRef/Release methods. But this kinda shows the problem: why is that necessary?
I work with Oxygene which is another modern Pascal -- quite a few new Pascals have popped up recently, I get the sense there's a real desire for something new! Our interfaces can be 'clean' and we support soft interfaces, too.
My real wish for Pascal interfaces is that they are pure. Some of that is not bringing in COM stuff (including recounting) because I think memory management is or should be different to interface-based clean coding. Another: In Delphi if you define a property in an interface, you have to bring in the getter and setter too. And that makes them implicitly public / visible (even if the implementing class declares them as private.) And they must be methods, there’s no way to say “read, but I don’t care how” (where Delphi can normally read fields too.) In other words, the semantic of “I want a property with read access” causes the interface contract to define the implementation, including making public the normally private / internal backing.
Whereas what I really want is to declare “property Foo: Integer read;” and the interface requires that is satisfied, but not how. In other words, interfaces are pure - they don’t bring in extra baggage. You can do that in Oxygene.
However my question was mostly with the objection against having a GUID, and how Supports() is solved without said GUID, especially since Delphi interfaces doesn't require a GUID in the first place.
But within one app, ie not crossing boundaries, perhaps their object model's vtable carries references to the interfaces, so casting of any sort to/from object-interface and interface-to-interface would work, including Supports?
Delphi is just very Windows-centric with a lot of things they do.
I'd love to hear more about how you're using Delphi and what it excels at, compared to current web and native software stacks.
And while the attention to backwards compatibility has been astounding, the move to Unicode-by-default strings was a non-issue for most unlike say Python, the language suffers and feels a bit tedious at times compared to say modern C#.
That said, for creating Win32 applications, especially CRUD stuff, there's nothing quite like it in terms of the efficiency of getting deliverables to customers.
What languages would be better in these ways?
[1] Homepage (terrible looking): https://fpgui.sourceforge.net/ [2] Github repo: https://github.com/graemeg/fpGUI/ The Discussion area has some interesting conversations and screenshots.
Only downside is Windows support.
I wrote one major project in UCSD Pascal on Apple II 45 years ago: my Honnibo Warrior Go Playing program. For its time, a fantastic dev environment.
I wish something like this existed for Ada :)
https://jxself.org/git/supernova.git
https://jxself.org/git/beyond-the-titanic.git
Ok, there's no way to bootstrap it without FPC... can the compiler compile itself?
Yes, Blaise reached self-hosting after just 7 days. Meaning it could compile itself, and was byte-for-byte identical to the bootstrapped version. The language was absolutely barebones, but that's not the goal at that stage. The first (FPC) compiled binary is called the Stage 1 binary. That binary then compiles the compiler code to make a Stage 2 binary (a read Blaise compiler binary). Then Stage 2 compiles the compiler code again to make a Stage 3 binary. Self-hosting is when the stage-2 binary and stage-3 binaries are byte-for-byte identical. Blaise has already achieved that.
I'm currently actively working on removing the FPC and GCC bootstrap requirements. After which Blaise would become it's own bootstrap compiler.