Lazarus IDE 3.0(forum.lazarus.freepascal.org) |
Lazarus IDE 3.0(forum.lazarus.freepascal.org) |
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
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
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.
Could this technique be used with Gtk4+Wayland as well?
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 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).
https://wiki.freepascal.org/Platform_list#Supported_targets_...
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
Can you explain or link to somewhere to read about this? Isn't psABI quite simple?
For everything else where Delphi may look like a good option... Well, for that there is Lazarus.
Well, there is a third reason, you want to have some company to blame (and ask help from) when things break :-P
It was a blast from the past for sure. Is this / Lazarus just a retro thing or do they have practical utility in 2023 also ?
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.
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).
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).
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.
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.
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.
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.
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.
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.
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.
Absolutely wrong.
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.
But Pascal is in no way related to BASIC.
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.)
To code some FOSS stuff, enjoy a fast compiler toolchain and RAD experience for GUI applications, worth a try.
The biggest weakness is that it's not great for iOS and Android.
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.
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
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
Is there some hidden context to these comments, like "we've all just inhaled industrial solvent fumes and then posted on Hacker News?"
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.
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.
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.
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.
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.
Maybe in Racket if you squint a bit?
Turbo Pascal 3.0 had an IDE with compiler and debugger in a binary less than 40kb (if the info I found googling is true).
I stand by exactly what I said.
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.
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.
It is not.
>"assembly "
It has assembly built in.
