This wont be part of a Lazarus release any time soon (ok, it might be in 4.0 but i don't know when 4.0 will happen) as it is only on trunk, but recently i was fixing bugs for the Gtk1 backend. The neat bit is that Gtk1 is very small and while it isn't preinstalled anywhere nowadays (except Slackware) you can carry the .so as they are around 5-6MB or so. However it also supports static linking and after some quick hacking i made Lazarus to statically link against Gtk1 but dynamically link against X11, etc, thus making binaries that can run in pretty much every distro (assuming of course what Gtk1 provides is enough). The neat bit is that the static binary is only around 1.5MB larger than the equivalent binary linked dynamically with Gtk2.
Here is a little mesh viewer test for some docview-like API i wrote recently (not part of Lazarus itself, this is part of a package i use with common code across my Lazarus apps) that was statically compiled with Gtk1 on Slackware running on a Debian which has no Gtk1 libraries at all[0]. Also a bonus screenshot[1] with another mesh viewer (this is a different project[2]) compiled twice, once with the Gtk1 backend and once with the Qt6 backend with the exact same code (just changed the target "widgetset" from the project settings).
God I only took a peek at the screenshots and I want that environment so bad. I miss it. I realise what it makes me sound like, sitting on my M2 32GB 1TB monster. Nostalgia hits you in the feels.
I'd say it's a lot more than _just_ nostalgia, though that certainly can play in too... But there are plenty of aspects of this, like snappy interaction latencies and a small pool of simple but consistent UI components that behave the same every time you see them, that I think are objectively better than much of what we see today. There was absolutely something lost in consistency and quality when we resigned ourselves to most UIs starting with a blank HTML DOM and building their own custom UI from scratch.
Does FPC avoid using versioned symbols from glibc that would prevent it from running on distros without a recent glibc, unlike any C/C++ program compiled using system libc headers?
This is a particular problem with recent Slackware-current: I used to compile portable x86/64 linux binaries (from C+C++ sources or from FreeBASIC compiled to C) by patching out those versioned symbols using ld --wrap= flags, but since glibc 2.34 even that no longer works:
https://news.ycombinator.com/item?id=32479545
I think there was some effort to allow specifying versioned symbols or something along these lines that was inspired by some breakage introduced by a recent glibc, but i don't know where that went.
However the safe and really recommended approach is to link against older libraries (easiest way is to use a VM running an older Linux distro), like with C and C++. Free Pascal is largely self-contained so Free Pascal on an older distro is trivial and even if you have to build from source it is just a couple of commands.
Well, Gtk4 isn't supported (in fact even Gtk3 support is buggy, AFAIK the original maintainer abandoned it after getting tired of Gtk4 breaking the API again - i think there is someone else fixing bugs for Gtk3 right now though but there isn't any Gtk4 code), though from a quick search it can be statically linked if you build it from source yourself (the Gtk developers do not seem to like that though and all comments i saw in a couple of relevant bugtracker posts were along the lines of "do not do that, we don't want to support that"). So assuming a Gtk4 backend is made and you are able to create a static Gtk4 library (together with static versions of all the libraries it needs aside from common stuff like the C library, OpenGL, etc) it should work.
It might be possible to link against Qt6 though (the LCL widgetset of which is more actively developed) but you'd still need to make a static library for both Qt6 and libQt6Pas (a "proxy" library that exposes a C API for Qt6 that LCL can use, currently it is part of the Lazarus project but there was some discussion recently to make it its own separate thing). Personally i've only tried linking statically against libQt6Pas (with the Qt6 libraries being linked dynamically so the program can use the distro libs) so i wont have to carry the libQt6Pas.so[0] (Qt6 is or at least should be available pretty much everywhere nowadays and will be around for years to come).
In general you should be able to link against any static C or C++ library (note that for the latter you also need to link against the C++ libraries).
I'm using this[0] version of Gtk which (AFAIK) is the latest stable Gtk 1.2 with Slackware's patches (gdk_pixbuf isn't the latest version, but i patched it to compile).
I do not see any Win32-specific code in there though, so it wouldn't compile. It might be interesting to try and make a Win32 backend (Gtk 1.2 was ported to Win32 but i think the port lived out of the main tree), especially a Win9x compatible one for retrocoding :-P. Though for Lazarus use it'd also need modifications on LCL/Gtk1 as in many places it uses X11 directly (and when it comes to retrocoding FPC and Lazarus do not support Win9x anymore, only Win2K and later).
I keep hearing about Pascal and Delphi, especially on HN, what is it and why is it special or talked about so much? I understand it's an older programming language but not why it's so loved. Any recommendations on how to learn it and is Lazarus a good option for the IDE or does VSCode suffice?
I've written a lot of Object Pascal (meaning the Delphi dialect of Pascal, not the older Apple dialect) over the years and... i don't think there is anything special about it :-P. It has a bunch of neat features (and a bunch of not so neat pitfalls) but really IMO the three main reasons to use it is that:
1. It has decent backwards compatibility (code i wrote even 20 years ago compiles either out of the box or with very minimal change - e.g. if you used strings as byte buffers or if you relied on some esoteric RTTI implementation details you may need to change some things but the changes are quick and trivial).
2. Lazarus is a fast and responsive IDE with RAD functionality for making GUIs (and other stuff, e.g. i haven't used it myself much but you can do things like configure visually via the IDE how a webapp will respond to various URLs) and FCL and LCL provide a rich frameworks for desktop applications.
3. The compiler is relatively fast. Delphi's compiler (at least the classic one) is much faster but compared to -e.g.- current C++ compilers, FPC is much faster (it takes less than a minute to compile Lazarus itself and AFAIK the codebase is more than a million lines of code - there is 2 million lines of code in the repo but you don't compile everything).
But linking is slow, plus also only possible using ld.bfd. This causes problems here as I default to gold... For now; each time you start using or close lazarus you have to remind to change ld target.
Otherwise compilation is indeed fast because it uses a system of cache (just like delphi *.dcu system) plus it has modules. On top of that we can add... context-free grammar that's fast to parse, no _insane_ preprocessing (but still some, $ifdef and co).
There are preprocessor macros though you need to explicitly enable them and they don't support parameters (there are workarounds but in practice they're not really needed). FWIW i never had to use them so far, the most i needed from the preprocessor was DEFINE/IFDEF/ENDIF/etc.
Delphi and Lazarus are a continuation of the beloved gui-first idiom where you are greeted by an IDE capable of running code at design-time. That means you can add an sql connection component, create a query, connect it to a data source, connect the data source to a grid and fill it right there while designing your form to see how the result will look like when you run it.
The second reason to use it is: it builds for many targets and runs without garbage collection.
Lazarus needs to recompile and restart itself in order to use packages, but other than that, it's pretty stable and fast. VSCode can be used to edit Pascal code, but it is pretty irrelevant.
It's funny how that sort of immediacy is what people like about lisps, but to my knowledge there is nothing like the RAD interface Lazarus and Delphi have in the open source lisp world.
> there is nothing like the RAD interface Lazarus and Delphi have in the open source lisp world.
The key phrase there is 'open source' I believe, because tools like Lazarus come out of a pretty distinct Borland / Windows culture of making bespoke usually paid graphical development tools. Lisps have a lot of their roots in the academic and Unix culture with a lot of folks seemingly allergic to GUIs to this day. There's an interesting interview with Carmack from a year or two ago talking about this.
It seems like there used to be more of a paid, proprietary, GUI using culture for Lisp, too, in the form of Lisp machines and products like that. They used to not only advertise their programming environment, but also advertise Lisp machines for things like 3D animation and editing office documents.
After learning BASIC in high school, as a CS student in the early 80's, my intro to computer science classes were taught in Pascal.
In college, we used DECWriter paper-based terminals and IBM 3270 terminals to write code. Our programs were batch processed on the school's IBM mainframe.
What's interesting to me is how well Pascal conceptually has held up with the current trend towards strongly typed languages.
When I look at Pascal source code today, it's remarkable to me how clean the syntax is. If our industry wasn't so driven by the hottest language/stack/framework that seemingly changes every 6-12 months, modern Pascal would still be a viable choice today.
Battlestar Galactica fans know the story line of how computers weren't allowed to be networked because that's what allowed the Cylons to gain access and nearly wipeout the human race.
In my fan fiction world, Free Pascal is the language the Colonies would use due to the Cylons exploiting the buffer overflows and the other issues of C/C++.
Kinda like: would we go the same route knowing what we know now about how using C for (nearly) everything turned out with vulnerabilities, etc.
For many people it was the first language they learned, which I think explains most of it. But the tooling was also very fast from a latency perspective, even on the slow hardware of the time, which tends to make for magical memorable experiences.
Turbo Pascal 2.0 had an IDE with compiler and debugger in a binary less than 60kb (if the info I found googling is true). Of course nowhere near the capabilities of modern environments but state of the art at the time.
Programming in Delphi was fun and easy. It's probably because things were overall simpler then, but we seem to hold on to the idea that it was the tool. And maybe it was, I haven't tried Delphi in a while.
It's nostalgia, for the most part, and I say this as someone who loved, and still love, everything about it. But I don't use it anymore and wouldn't recommend it to anyone.
Everything started with Borland's Turbo Pascal back in the 1980s. It was an IDE with a lightning fast compiler and built in debugger. Extremely slick, and it was so fast that there was hardly any time to wait for a build. It was extremely small and produced fast programs. And it was very affordable. Everyone loved TP.
As a language, TP implemented its own dialect of Pascal that turned what was originally a somewhat clunky, limited teaching language into a "real" language; for example, TP had assembly language built in, so you could write hand-optimized code for things like low level graphics. Eventually TP added object oriented programming that rivaled other languages like C++. This was before modern languages like Java and C#.
Borland released a Windows version, but it was basically the same thing but with a GUI. To write GUI apps you had to use a library called OWL and basically define the UI in code, by creating objects like buttons and fields. It was quite good, and played to TP's strengths, but real game changer was Delphi, which ended up becoming TP's successor. It was an IDE which supported everything TP did, but reoriented it around designing Windows GUI apps visually.
In Delphi, you built your UI drawing components and dragging them around, laying out each window and attaching behavior such as click handlers. Some components represented non-visual components such as database connections. The beauty was what they called "two-way editing". Changing the GUI updated the code, and vice versa. A key concept was that the components you were editing were "live"; they weren't mocked-up versions of anything, but actually ran your code right inside the IDE. Programming in Delphi felt more "live" than with other stacks (like Visual Studio) because the whole design-build-test lifecycle was so fast.
Many people considered Delphi to be a more advanced, "grown up" alternative to Visual Basic, which emerged around the same time and was in many ways quite similar, though Delphi was arguably much better. And indeed, since that time, nothing has really managed to match Delphi's ease of development; not VB, not Interface Builder, not whatever Sun was doing with Java and Swing at the time. Tons of people were extremely productive making GUI apps in Delphi, and as with TP, there was a strong developer culture around it, especially in Europe.
In both the case of TP and Delphi, the language was probably the least interesting thing about it. Pascal has always been a little verbose and clunky, and people succeeded despite of it. People who didn't grow up with TP/Delphi who look at it today will almost certainly wrinkle their noses at the sight of this language, and they'd be sort of right. It was never a great language. But it was an incredibly productive one. The speed, elegance, and "vertical integration" of these IDEs were significant force multipliers.
Delphi started to lose for many reasons: Borland's mismanagement, Microsoft playing hardball with them, the emergence of Java, the emergence of the web, the steadily increasing dominance of C++ (and rejection of niche languages), and so on. The fact that ObjectPascal was a niche language meant that Borland was always the underdog and suffered from poor interoperability with standard C/C++ tools; Delphi didn't consume C header files, so a new C library (DirectX or MAPI or TAPI or whatever) always required manually writing glue code to talk to it. Delphi fans were loyal, but they were always second-class citizens on Windows. (Even though Borland eventually launched a C++ version of Delphi, it never really caught on.) The world's focus away from desktop apps to web apps was just one more thing Delphi couldn't keep up with. And I say that as someone who wrote Microsoft IIS web servers in Delphi for a long time and built products that required interfacing with C libraries.
If Borland had been able to keep their eye on the core product and stay true to their development tool company roots, they might have survived to this day. But they didn't. TP and Delphi are now relics of a bygone era, much like the Amiga, the Acorn, the Nokia Communicator, and other examples of "superior tech that never took over the world." But like those other examples, the superiority is local to that era. You wouldn't bother using an Amiga for your main work today, and I wouldn't use Delphi. ObjectPascal was neat, but today it's antiquated compared to languages like C#, Rust, and Go. Delphi was always Windows-only, and these days cross-platform support is more important.
I should add that I've never used Lazarus. It looks like a Delphi clone, and it's probably quite nice.
Great insights, thanks. I used Delphi for a little bit and thought it was nice (much better and more "professional" than Visual Basic), and wonder what happened to it.
Back in the day, there were a lot of great widgets for Delphi and a lot of small companies selling commercial widgets. That ecosystem made Delphi (and to some extent, C++ Builder), extremely popular.
Most of those vendors moves to .NET (usually C#) over the years, and eventually, to the web.
For comparison, Qt, which is awesome, has never had such an ecosystem.
(watch at 2x speed for an idea how fast I worked at the time :=))
I won't describe features that are no longer unique. Most other IDEs have catched up, but twenty years ago, Delphi was much better than anything else. VB had a similar style, but the Object Pascal language was more powerful. Also you were able to program IDE plugins.
The work that FPC and Lazarus teams have done is incredible. Borland was a big SV company. These are voluntary programmers and have outdone Delphi.
Edit, with one more thing: you could program Delphi components (and you can program Lazarus components) using the same Object Pascal language used for the applications. Components can be graphical UI controls (special buttons, edit boxes, calendar pickers, etc.) or non-visible database, communication, processes, really any kind of objects, that can also interact with the IDE.
Pascal was used in the USA for a time on the high school AP tests (advanced placement) which are often used for college applications. So some know it from that.
As well, Wirth was an influential computer scientist and he had many students who went on to do many other things in both the Pascal family of languages and others as well. So his former students have influenced computer science also.
PASCAL was invented by Professor Niklaus Wirth at ETH Zurich specifically for teaching structured programming, circa 1970 (year of first release). It's a descendant of ALGOL (1960), which was pretty much the first structured programming language and introduced functions that could be recursively invoked -- ALGOL is the ancestor of C and PL/I as well as Pascal and relatives (Modula-2, Oberon, etc) and is hugely important.
BASIC came out of Dartmouth College in the US in the mid-sixties and the emphasis was on interactive invocation: early BASIC was almost completely non-structured (GOTO for flow of control, minimal subroutines, IF statements with no ELSE).
While both Pascal and BASIC were intended as teaching languages, they took radically different views of what to teach. And Python is different again: Python has the virtue of a simple and consistent core syntax, but wasn't designed for teaching -- it was designed for scripting, and was developed in the early 1990s for computers with 2-3 orders of magnitude more resources than early BASIC and Pascal.
Object Pascal/Delphi (Delphi was Borland's proprietary implementation with RAD for Windows) is an outgrowth of Borland's Turbo Pascal from the early 1980s, which in turn took Wirth's Pascal and added some essentials that had been missing -- notably dynamically allocated strings, modules, and finally object encapsulation -- that made it much more suitable for writing serious code: for a while Turbo Pascal was a viable competitor for C on MS-DOS.
In practice, it was taught as an introduction to programming.
For a decade or two, children learned Basic and highschool/JC aged kids learned Pascal.
Of course they aren't the same thing. It'd be like saying kids ride tricycles and then bicycles and clapping back about penny farthings, velocipedes and dandy horses while tricycles started as a wheelchair device.
Give me a break. The point was Pascal is accessible and easy to learn.
I've met both Kurtz and Wirth and I'm sure they wouldn't have a problem with this.
I think the post you are replying to got it exactly right. IMO your post got it all wrong.
>"I've met both Kurtz and Wirth and I'm sure they wouldn't have a problem with this."
Modern Delphi/FreePascal and the one created by Wirth are very different. I would not call it the same language. And what you "sure they wouldn't" is totally irrelevant.
From the perspective of the learner, the actual cognitive work to get to mastery is of a similar order of magnitude and similar nature. The feature crossover is probably 80-90% depending on how you choose to enumerate them.
The question was about that, specifically, not about the history, not about the nuanced details of who created it, but about how hard it was to pick up.
Specifically "Any recommendations on how to learn it"
It's not in the class of R, FORTH, assembly or Haskell. It's not like Erlang. It's as conceptually approachable as Basic and historically was taught after Basic to tens of millions of people over the course of two decades, in that order.
Java is also a more sophisticated basic and is commonly taught as an introductory language.
I’d much rather be taught Pascal than Java. Probably 20 year old me would feel differently, but the 20 year old me was a much worse software engineer (actually, he was just a self taught programmer kid.)
right. "First Language" is a moving target and it is not something a language wants to have because you get a bunch of really crappy code in that language and it ruins the language's reputation.
After the rise of the web in the early 2000s it moved around a bit. Java, PHP, Ruby, Javascript, even Flash sometimes, but now it's generally Python and it's so far bucked the trend and managed to remain respectable. Pascal and BASIC had a grip on that slot probably since the late 1970s through maybe early 2000s. Before that it was Fortran.
I did y2k stuff 25 years ago, there's a lot of shit fortran out there.
The code generation has been pretty good upstream for many years now. It's easy enough
The hardest part of adding full support for RISC-V is to support the hardware floating point ABI. It's incredibly complicated for likely no real world reason. It will likely require a ton of code still to make freepascal fully compliant
The software and ABI ecosystem of RISC-V is what made me personally lose my love for it. The ISA is great
It's that structs of two simple fields need to be passed in registers. And more specifically that this rule is relevant for mixed integer and floating point fields.
It's a very specific rule that requires a ton of code to implement compared to the integer calling convention. And again like the weird AMD64 convention likely invented to squeeze out a theoretical few cycles that never occur outside microbenchmarks
Lazarus license make it so much better than Delphi that I can't find a reason to justify using codegear's solution nowadays other than legacy code. It is not that their alternative isn't good, on the contrary. The problem is that they simply can't win against the competition: they can't win over MS tools for windows, they can't win over Apple's tools on MacOS, they can't win against FLOSS tools for Linux.
For everything else where Delphi may look like a good option... Well, for that there is Lazarus.
IMO there are two main reasons nowadays to check codegear's IDEs: you either have some huge Delphi codebase that you can't move anywhere else or you want C++ support with a full RAD IDE (i do not think there is anything as RAD-y as C++ Builder). QtCreator is a workable alternative though.
Well, there is a third reason, you want to have some company to blame (and ask help from) when things break :-P
RAD, now there's a term I haven't heard in 10 years. Can you unpack how one modern compiled language can be more RAD than another? I thought it just meant having an IDE.
In the context here, it is about rapidly making a GUI by visually editing widgets, usually via drag and drop, pretty much like placing shapes in a power point slide. The IDE doesn't just contain a source code editor, but also that visual window/form "designer" (in Visual Studio jargon). The RAD IDE generates the GUI code from what you've drawn, instead of you having to manually type it yourself, hence the "Rapid" part. To attach code to an event (i.e. click) you often simply have to double click on the corresponding widget/control in the visual designer, or use the corresponding "Event" GUI element somewhere in the IDE. This was in contrast to how it was done with C++ options such as MFC prior to Visual Basic / Delphi.
It gets GUI layouts done fast, but I also think it has some drawbacks. Manually drawing controls, i.e. sizing & positioning, eventually becomes a tedious chore once you have a lot of them or if you anticipate frequent updates in the UI. One trick I always end up using is just using some simple math to do the layout as the form resizes. In C# + Winforms, I'd go further by bypassing the visual designer as much as I can and just manually spawn the widgets just like any other object. Other UI frameworks also assist in layouts or just don't make this a problem to begin with. For example WxWidgets, Qt and, if I'm right Ultimate++, have sizer/container controls that do the layout logic.
Note that in Lazarus / Delphi things aren't exactly like that: while the IDE does generate some code, it is largely declarations for the object instances and event handles. There is no code generated for building the GUI itself, instead the framework uses language features like the RTTI and metaclasses to implement object serialization and the IDE is modifying live instances. Check my sibling comment to yours for more details.
Also note that Lazarus has way more layout functionality than what you'd see in, e.g. WinForms (in fact IIRC WinForms is even more limited than the version of Delphi that existed around its introduction). In addition to a simple "Align" property (which existed in Delphi and also has something similar in WinForms) that allows placing components at the edges and/or center area of a container (which already allows you to do a lot of layouts, e.g. many "vbox"-like layouts in other toolkits can be done in Lazarus/Delphi by setting the Align property to "alTop" or "alBottom" in all of the container's children - similar with "hbox"-like layouts by using "alLeft" or "alRight") it also has an "anchor" functionality that allows either anchoring the edges of control in place (so that, e.g., if you resize a form and you have a button anchored to the left and right sides, it will be resized horizontally) or specifying how controls relate to each other via their edges. This allows you to do things like having one button have its right edge anchored 10 pixels from to the form's right edge, its left edge not being anchored anywhere, a listbox's right edge anchored 5 pixels from the button's left edge and a bunch of other buttons having their left and right edges anchored to the left and right edges of the first button while their top edges are anchored to one of the other buttons so they form a stack. Almost all controls have an "AutoSize" property which allows them to resize themselves automatically (often to fit their contents - or, for containers, their children), which essentially means that you get automatic layout that works when forms are resized and regardless of font sizes, etc. When anchors are not enough, all containers have a ChildSizing property which allows you to specify some simple automatic layouts for children, like using row-major or column-major ordering, having them use the exact same width and/or height, etc. Finally if none of these are enough, there are some other layout-related controls like a splitter (which automatically adjusts the width of controls laid out via the Align property), pairsplitter (which provides a container with a splitter in case Align isn't enough), flow panel (which lays out children in various ways like, left to right, right to left, top to bottom, bottom to top, etc with wrapping based on rules you set for each child), scroll box (which is basically a container with automatic scrollbars when the contents do not fit), etc.
Also note that all the above are done visually without any code, though of course you can also write code if you want. It is just that it is way more rare to need to do that, especially when compared to WinForms or (worse) classic VB.
Personally whenever i make a GUI in Lazarus i place the controls manually approximating how i want the layout to be and then open the anchor editor and start assigning relations. This is enough for 99% of the layouts.
Part of what signaru described but in Lazarus/FPC (and Delphi) it actually generalizes more - it isn't just the GUI that you can edit visually in the IDE and you aren't just editing some sort of visual stand-in/proxy: instead what the IDE edits is "live" object instances, there is support for properties at the language level as well as enough RTTI and metaclass functionality to be able to reflect an object's making and state at runtime, which allows for things like object serialization and editing said live object instances via property editors. In Lazarus (and Delphi) programs are made up of "components" (which are just subclasses of the TComponent class) and these components lie inside "packages" which are basically libraries - the same libraries your program will use - that are linked against the IDE. The libraries register the classes with the framework and the IDE (which is written against its own framework) queries the registered classes and can use them in the visual designers: when you place a component on a form you are creating an instance of a registered component class, the properties of that instance show up in the object inspector allowing you to edit them in place. When you save the form, the objects in it are serialized to the form file.
This is how the GUI editing works, but there is more to that since components do not have to be visual elements. For example check this screenshot[0], this shows some components from a package i have written that i use across various tools (mainly 3D related). The edited form (which btw is a component itself) has a visual component that represents a 3D viewport (the big black box) and four non-visual components, a component that represents a fragment/vertex shader pair for OpenGL, a component that provides undo/redo management, a component that represents a manager for all viewports and a component that can be used to render multiple viewports at the same time. The first component (the shader pair one) has its properties shown in the object inspector at the left with a "strings" editor opened for editing the FragmentCode property (which is a collection of strings meant to represent lines in an editor) and shows some GLSL code. The undo manager has its own properties and two of them are "UndoAction" and "RedoAction", meant to be assigned to "TAction" instances that will be automatically updated whenever undo events are handled. TAction is a non-visual component provided by Lazarus itself that can be used to represent GUI actions that can be invoked via various places (e.g. menu items, toolbar buttons or programmatically) so that instead of writing code against menu items, buttons, etc directly you write the code against the action and then associate the action with the menus, buttons, etc you want.
Another thing to note is that so far i mentioned GUIs but Lazarus (and Delphi) is not limited to that. As i wrote above a form (window) itself is also a component but there are also non-visual "toplevel" components too: data modules. These can contain only non-visual components (and you can even use them in non-GUI applications, e.g. command line applications or web applications). Some are used to "RAD" only meaning GUI editors and might find that weird, but if you take all of the above in consideration, it becomes obvious that since you can edit non-visual objects in a form via the IDE you may also want to be able to edit only non-visual objects in a non-visual container (which also allows making programs without a GUI while still being able to edit objects visually via the IDE).
In fact one may use the aforementioned actions but placing them inside a data module instead of a form, thus separating the logic of the program from its GUI while still being able to take advantage of the IDE's visual editing functionality.
In a way it is similar to how some game engines like, e.g. Unreal Engine, work (though UE needs a preprocessor to generate the class information while Lazarus/Delphi use language features) and is probably among the closest you can get to a Smalltalk-like environment without being able to serialize the entire environment to disk and instead working on a traditional "edit, build, run" cycle with clearly separated "editing" and "running" states.
Lazarus isn't retro. It's an open source, Delphi-compatible IDE.
If you are a big Delphi fan and would like to port your apps to non-Windows OSes, try Lazarus.
I'd say not even just FOSS, but indie developers can get a lot of value out of Lazarus and Free Pascal. It is by far the easiest way I've found to create a quick cross platform desktop application. When I say quick, I mean quick to develop, quick to compile, and it produces native binaries (using the native toolkit!) that are quick to run and use less memory than the alternatives.
The biggest weakness is that it's not great for iOS and Android.
> Lazarus just a retro thing or do they have practical utility in 2023 also ?
Surely it's not a retro thing. As for being useful in 2023 for landing a job, well, most head hunters won't even know what you mean if you mention it in your resume, however if you're lucky enough to find a place where they don't dictate what you're forced to use but rather ask "we have a problem, can you solve it? You have carte blanche wrt tools", chances are that by using Lazarus you can be extremely productive in short time.
Technically the only reason FPC's textmode IDE is "retro" is because everyone is using Lazarus instead :-P so it doesn't get much development. It is useful when you want a more lightweight FPC development environment or to develop in a platform without Lazarus support yet (i think Haiku was like that though from a quick search it looks like Lazarus can run on Haiku now with the Qt backend[0]).
There are a bunch of programs using Lazarus though, e.g. AFAIK the 64bit version of Total Commander is made using it.
Personally i'm making a bunch of stuff using it, like a 3D game engine[1] (well, actually more than one[2][3], but that is retro :-P), various utilities (e.g. some time ago i wrote a utility to repeat a texture on a spline so i can use it to draw patterns on textures[4]) and experiments (e.g. a lightmapping experiment[5] i wrote last year). Though as i like retro stuff, some of my projects are of that nature (e.g. aside from the second engine mentioned above, i wrote a quick and dirty Quake map editor[6] and a dungeon/map editor[7] for a homebrew game i was making for the OG Xbox using the opensource nxdk SDK - the game was made in C though, only the tools are in Free Pascal and Lazarus).
EDIT: forgot to mention, in a previous gamedev job i used Lazarus to write a tool for extracting savegame data for an external QA company, a tool that analyzed resource/asset usage for the engine and could point out exactly where it was loaded with full backtrace (i used Lazarus' "SynEdit" control to show the C++ source code for that with syntax highlighting and move to the exact line) and a tool that analyzed memory use and found untraced memory (the engine had its own memory allocator but not all memory went through that, especially from some middleware, so i wrote a tool that hooked VirtualAlloc and traced its callers - a hacky solution but worked :-P).
Years ago I was discouraged that there is a lack of a grid component like WPF's Grid or Delphi's TGridPanel. Something that I can specify the number of rows/cols and their sizing. Has this changed since? Or perhaps this is achievable nowadays with (nested?) TFlowPanels?
If i understand what you mean, i don't think you need TFlowPanel at all and you can just use a regular TPanel (for small grids) or TScrollBox (if you want scrollbars) and modify ChildSizing with Layout set to cclLeftToRightThenTopToBottom and ControlsPerLine to the number of columns you want. You can also set the spacing properties to allow space between the controls and/or the Enlarge/Shrink Horizontal/Vertical properties to force children use the full width/height. I did a quick test[0] and seems to work fine. Note that as this uses the controls' automatic sizing, the controls will always be resized to match their autosize, however you can use the Constrains property to set a minimum (or maximum) size and/or use a TPanel for a "cell" so you can specify whatever size you want (or have cells with multiple controls).
Pascal was the first language I tried in my youth, it has forever imprinted my understanding of programming. I'm both immensely thankful and perplexed by it.
Me too. But deploying to web unless it's a Steam game, console game, video editor, DAW, audio-editor, 3D-modeller or graphics editor seems to be the way to go. But mostly they would benefit from heavy GPU use and something like OpenGL or Vulkan.
An IDE similar to Lazarus, that creates executables for those non-web cases, and has the GPU in mind, and supports Go (+ Rust, Zig, Mojo, Swift, Nim, Crystal, Odin and Hare), would be fun.
Here is a little mesh viewer test for some docview-like API i wrote recently (not part of Lazarus itself, this is part of a package i use with common code across my Lazarus apps) that was statically compiled with Gtk1 on Slackware running on a Debian which has no Gtk1 libraries at all[0]. Also a bonus screenshot[1] with another mesh viewer (this is a different project[2]) compiled twice, once with the Gtk1 backend and once with the Qt6 backend with the exact same code (just changed the target "widgetset" from the project settings).
[0] https://i.imgur.com/Y4jvQMk.png
[1] https://i.imgur.com/NE2LB3U.png
[2] http://runtimeterror.com/tech/jtf/