Lazarus IDE 3.0 (opens in new tab)

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.

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 like the idea if including the UI library. I know that ie. Ardour are not looking forward to upgrading from Gtk2.

Could this technique be used with Gtk4+Wayland as well?

Would this GTK1 version work with Windows as well?

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).

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.

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.

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.

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.

The nicest thing is the IDE, so using VSCode you're missing the point.

https://www.youtube.com/watch?v=MvFCgc_YvAs

(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.

It's not hard to learn. It was often taught as a "first language" the place that I guess Python occupies today. Essentially a more sophisticated BASIC

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

RISC-V is inevitable.

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

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.

Do get a job in 2023 coding in Object Pascal, probably not.

To code some FOSS stuff, enjoy a fast compiler toolchain and RAD experience for GUI applications, worth a try.

> 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).

[0] https://i.imgur.com/Rl8ISmQ.png

[1] https://www.youtube.com/watch?v=SQ1-r9aE0QA

[2] https://www.youtube.com/watch?v=m5IAIhWcco0

[3] https://i.imgur.com/3f64T9M.png

[4] https://i.imgur.com/hfXWYAe.png

[5] https://i.imgur.com/ahO15LO.png

[6] https://i.imgur.com/7MSH98p.png

[7] https://www.youtube.com/watch?v=u1Mf8ujCu5g

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).

[0] https://i.imgur.com/DZBrSvh.png

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.

You are in luck - https://github.com/ying32/govcl