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.
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?
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.
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
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.
Congratulations on your projects, Graeme!
When Blaise gets an IDE, make sure the editor component is modern, pleasant to work with (like vscode, for example) and with proper support for fonts. All things that Lazarus missed.
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).
24 comments
[ 3.3 ms ] story [ 56.8 ms ] threadWhat it lacked was a modern compiler and stack. There is FreePascal for sure, and Lazarus is impressive, but it for sure has its baggage.
I wish something like this existed for Ada :)
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.
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
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.
This part isn’t true, for many years now we’ve also had Oxygene - https://www.remobjects.com/elements/oxygene/ (also proprietary)
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?
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/
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 find with-style code so convenient that I recreate it in other languages (auto _=&foo; ...)