Delphi still exists and is actively developed
embarcadero.com
embarcadero.com
However the lack of ways to design non-trivial UIs quickly does not make it seen feasible at the moment.
Then there's the fact that Win32 is like bedrock in terms of stability. We've got forms that's been designed and coded over 15 years ago which still works just as fine as they did back then.
We've got input-heavy UIs, the one I'm working on right now is a single window with >150 input fields including multiple child tables up to levels 3 deep with their own grids. Getting the UI layout done and components connected to the DB will take me a day tops, it'll look great and based on history should work for the next 10+ years. The web seems like such a step back whenever I try it.
Yeah i’ve built single page apps with more input fields than this and grid tables all in a single view. Are you sure this cant be easily done?
Coincidentally that was first 15 years ago with extjs, second time with react 3 years ago - the latter being a slower process but still pretty much doable.
No, I'm no web expert. We've not found a way so far, and I've not seen something like this on the web, but I'd be happy to be proven wrong.
edit: to clarify, I don't doubt one can get 150 fields in a view on the web. But can one dev do it in one day and have it look great?
I think you are doing your customers a great disservice by not learning about web development.
Win32 is bedrock, the web is quicksand. Look at "HTTPS everywhere" and "you don't need FTP any more", which did little in terms of actual security, but broke almost everything in some small way.
The web doesn't value legacy. It's a petulant 22 year old, that thinks it knows everything, and does stuff deliberately against the advice of those with more experience.
Is the web as stable as Win32? No, of course it's not. But a page with 150 inputs isn't anything that requires cutting-edge web technologies. It'll work just as well today as it'll work in 5 years.
Sticking a bunch of inputs in a HTML page is indeed not complex, but it has to look decent (labels and corresponding inputs line up vertically etc) and be functional (ie with sensible tab order etc).
To get a sense of what we've got in Delphi, here's a demo video[1] illustrating making a simple input box. This is a "entry level" demo, but it's representative (though we don't use the runtime customization).
I'd really appreciate input on something which could allow us similar decent looking UI with similar effort on the web.
Like, note how "Last Name" lines up with "Product ID" below, even though they're in different groups. Things like that.
How do you handle the transition at 2:04 where "Last Name" is moved from its own row to sharing a row with "First Name"? Keep in mind I might want to add a third element in that row afterwards.
IIRC with tables you'd have to modify the column spans of all the other rows which is way too much effort. How does it work with the CSS grid layout?
This is pretty simple with CSS grid -- literally takes a couple of seconds. I am a fan of Delphi, and used it myself in the late 90s, but I think you just might just give it more credit due to familiarity.
There are benefits to a web-app these days, due to the onerous requirements and demands of different operating systems and platforms.
Fair enough. I've tried searching for these things but it's very hard to find good resources. So far I've not found a way to do this with similar ease, but from this thread it seems it might be possible after all.
Some concrete examples or resources would be much appreciated.
> There are benefits to a web-app these days
Sure, I definitely see the positive sides of a web application, especially for our smaller customers.
Ok. I am not sure of your current front-end experience level, so I will give pointers as if you are not experienced with CSS grid, forgive me if this is incorrect.
The key CSS items in this case would be:
display: grid;
... which will allow for CSS grid layout, and then for the particular item you discussed, the following two CSS values would do the trick.
grid-template-areas .... for the layout container itself in a pseudo-visual way, and grid-area for the items to be laid out.
Here[1] is a simple example, but if you are a visual-type person would get the idea across.
[1]https://developer.mozilla.org/en-US/docs/Web/CSS/grid-templa...
The demo at the top of the page is interactive and you can see how easy it is to move around items. Of course these items would already be styled themselves to maintain label positioning and alignment so simply moving the letters in the grid-template-areas value would be sufficient to completely change the layout.
This does not let you drag and drop as in your demo, but it is equally fast and gives instant visual feedback in the browser.
As a side note, I morn daily the continuing loss of desktop applications, which is where I cut my teeth in development. But the explosion of platforms and continued aggression from OS manufactures in the name of "safety" is basically forcing the hands of people to move to web apps. I agree that, in general, they are not as snappy or as light-weight as a well-designed desktop application (a "real" one, not an electron app), but if you know what you are doing you can get close and get all the benefits that do come with web apps.
And, from someone that has done both desktop and web app development, web apps can be laid out very quickly if you have experience. I almost can not think of a single-page (non-animated) application that I can't layout in a single day. This is especially true if you are using an existing UI framework or you have built-up one of your own over time. The time-consuming parts tend to be testing on multiple platforms/screen-sizes for compatibility (iOS being the worst) and the business logic.
Let me know if that is not the type of info you were looking for, and I will be happy to point you in a direction to get the info you are looking for.
Will definitely take another stab using this. I'm assuming the grids compose, so I can work on one group (say name-address set) and it'll be well behaved when added into a larger layout grid.
The WYSIWYG drag and drop is nice, but if the results are predictable enough a manual "edit-and-run" cycle should suffice.
> Of course these items would already be styled themselves to maintain label positioning and alignment
So I guess this is the only thing I'd still be struggling with. Concretely, consider a grid layout like this:
a b
c c
d e
Here each cell has a label and a text input. Here the labels and inputs in a and d, as well as b and e, should automatically line up vertically, including if say b's label changes due to a dynamic event.I'll have to see if it's easier with the grid layout.
Yes. That will work as expected.
>Here the labels and inputs in a and d, as well as b and e, should automatically line up vertically, including if say b's label changes due to a dynamic event.
This is where not rolling your own UI elements are faster. They will have been tested and any serious problems would have been addressed. But, even if you do roll your own, you can expect to be able to line up labels and fields both vertically and horizontally, even if the labels dynamically change (although watch for line wrapping if that is a possibility).
But, generally, your idea would work. I typically use flexbox unless I have a reason to use grid. For example if the entire flow of a page design changes between desktop and mobile, I normally use grid or if I need things consistently centered both vertically and horizontally, I use grid.
For laying out form UI elements, there are tons of examples that you can easily find online to fit the look and feel you are looking for.
If you have not settled on a stack yet, Svelte and Solid will offer the snappiness you are used to with desktop apps (due to no duplicate/virtual DOM). The drawback being that plugin elements are more readily available for more popular frameworks like React, however imho the plugins for Svelte or Solid tend to be better written.
And I've seen Delphi apps; I recently worked on one. In my experience they don't look great. Maybe you've done a lot of work to theme the controls; if so, wonderful. But what I'm familiar with just brought up Windows dialogs, and ... well, that's functional but I wouldn't say it looks great.
But here are a few examples of ways you could create 150 fields in a day on a web app and have them look great:
Arrays of control types: https://formik.org/docs/examples/field-arrays for simplicity of creating the controls plus something like https://chakra-ui.com/docs/components/input to make them pretty.
Spreadsheet look (with spreadsheet functionality!) in one control: https://www.npmjs.com/package/react-spreadsheet
Want to build the form by hand and customize it? https://www.form.io/
Form should follow a database schema and automatically display database records? https://marmelab.com/react-admin/ (I used this approach to bring up an admin panel for more than 150 fields, though spread over a couple dozen pages, because of course that looks better than trying to bring up 150 fields on one page.)
The standard way to create a large form (or any data table on a page) today is to iterate over the fields you want and add them to a page. There are frameworks like Chakra that can help you make everything look attractive--and you can theme the result in whatever color scheme or styles you like.
I really don't want to have to touch Delphi ever again; it felt like I'd fallen back into the 1990s in code development terms, and I missed all of the modern features I'd grown accustomed to. If it's what you like, and it pays the bills, then enjoy. But know that people who have used more recent tools like myself consider it to be anachronistic.
But that doesn't mean I want to work on it.
Simple is beautiful.
> And it's a utility that really doesn't need to look fancy, so it's fine for what it is.
"Fancy" sucks.
> It doesn't seem to have a dark theme, which is a bummer, but otherwise it does the job.
"Dark theme" is moronic: Having your app use only standard Windows controls meant it automatically used whatever "theme" the user had set Windows-wide, so it always adapted to their preferences. No per-application "dark theme" or "purple theme" needed.
Until Microsoft themselves sabotaged all that, starting late in the lifespan of Windows 7. Assholes.
Delphi has almost none, while most tech I have seen on web has a lot of it.
Edit: However, my challenge is on wether it can be done or not. Delphi is cool, and tbh any tool you are an expert in will let you do something quicker than a tool thats new for you. It will probably take me a while to achieve the same goal in delphi.
I'm... not sure this is true. There are plenty of ways of designing non-trivial UIs on the web.
I'm kind of curious now.
Delphi claims you can "Build Native Apps 5x Faster With One Codebase For Windows, Android, iOS, macOS, and Linux" the biggest corollary I can think of there is Election, and we all know how we feel about Electron apps here.
I went through this transition in the late 2000’s, moving grid and form heavy delphi windows screens to webpages, using ExtJS, the only framework at the time which kind of sort of could do this.
The process made me realise two things:
1. if you try to map information-dense UI’s like that to the web, it will cost more to develop and the UX will be worse. (we saw double the dev cost and a slower and more cumbersome ui)
2. in most cases information-dense UI like that is bad design and should be avoided. I couldn’t see it back then how things could be done differently to make screens less dense, but looking back there were plenty of ways.
We do auto-expand a lot of groups, ie for company name and address fields we might just show name and org. number until you enter the company name field, at which point we show with the full name and address set. Once you leave the group it collapses again.
Still, the information-dense UI is what our users like, as far as I can determine. They want to take one look at an order or invoice and get the info they need, not having to flip through several tabs or pages.
Part of this is also driven by gov't requirements. That is, users are officially responsible for the data they submit, so they must be able to see all the data they submit.
Web interfaces are extremely clunky to use when trying to do things via only-keyboard (which is the only way to have muscle-memory help you zip through forms) methods.
They are slow to update and in some cases, the Web browser's UI is fighting with you, such as offering to replace your input with the previous data you put in a form field of the same name, etc. In certain cases the tab method of navigation between fields gets broken or something else that interrupts the person's flow happens.
Having worked in a case where the ticketing system and related interfaces were half-Web and half-Java-application-on-Windows - even the Java application was better to use via the keyboard.
If you are paying people on a regular basis, whether hourly or per-shift, and the UI slows people down by 5% , what is the cost over the (perhaps) 3 years of that application's life?
Even 4 users at $50k/year each in the USA (with healthcare and other business expenses etc. that means a $20/hour full time job) means $10K/year (5% * 200K salaries) in extra expense.
You surely have noticed how employees speed hack away on the keyboard with those old terminal style TUI apps.
Modern UX is almost all about looking sleek to the procurer, not usable for the end luser.
You can use tab and hotkeys, add hints for auto fill (or just straight disabling them for a page).
Normal UIs are fast enough.
I'm not necessarily advocating for only web but I don't think your arguments holding up with reality
We've yet to receive a HiDPI bug report, but we do get reports when we forget some customers still run 800x600 screens...
And note that this happened before the web pillow-smothered decent desktop UIs. If it was all about a reduced audience for desktop-based applications and then supporting that, I would understand it more.
I haven't been following Delphi itself, but the parent company also manages ExtJS, which is aimed/priced similarly, yet with support/quality that doesn't justify this.
Weird that outside of the BCPL or ML families, it's Ada that seems to be the one with the most momentum these days.
the web pillow-smothered decent desktop UIs
Application development has gone backwards so much compared to the RAD tooling from the 90s. I really can't even properly describe it to the younger generation. :(As soon as you introduce layouts to your UI, all the Delphi simplicity goes out of the window.
This is an interesting challenge to invent a way for UI to be pixel-fixed, yet work in web and with localization. If someone would do that, you could rebuild Delphi for web.
I guess one way is to build a pixel-fixed form for English language and let AI to build a layout for this form.
Granted, it wasn't as easy to set up properly vs modern web layout engines - but there is so much more to RAD applications than the UI layout by itself.
They weren't lower then, they're lower now.
> Sure you could throw together a professional UI in a lot less time, but part of that was that the definition of "professional" was "looks exactly the same as every other Windows application and uses the same 5 form elements".
Yup. That's still the correct definition.
> We've just come to expect more variety so the RAD approach doesn't take you as far these days.
Yes, unfortunately users have been conditioned to expect myriad variations of something like Kai's Fucking "Power Tools". And most of them have even been deluded into thinking of that as a good thing. They're wrong.
Also, they should have had some better pricing, something like: Personal use: Free. Commercial use: Free until you are making $x a year, like Unity I think, and then different prices.
Note: I might remember wrong, as this was so long ago. I started with Delphi 1.0!
Which is the sad thing. Even if Idera were to change their tack, it wouldn't matter anymore, as there's no broad appeal for a "desktop full stack" solution anymore.
Right now, it doesn't matter anyway. They're in that enterprise tier along with commercial Smalltalks and APLs, even if they'd give away everything for free tomorrow it wouldn't change the world of computing.
https://www.embarcadero.com/products/delphi/starter/free-dow...
The IDE's are, however only runs on Windows (Or Wine if you're brave, YMMV).
For the interested, a free Delphi IDE exists (comes with FreePascal compiler): https://www.lazarus-ide.org/
Something that lets me draw a window with two number fields and a button that says "return sum", but it's two minutes of work and self-explanatory.
Maybe hard pressed to call it modern, but WinForms is still my go to for quickly making a UI, at least in Windows.
Basically Win32, Forms, WPF for .NET, Win32/MFC for C++, or web stuff like ASP.NET, possibly with Blazor.
Even though UWP did not went away, and they keep at the N interaction of it with WinAppSDK, I would lose any sleep over it.
Now working in SwiftUI, which is declarative but in a more understandable way, with a View building mechanism behind it that ties things together so that you understand what you're doing a bit better. Not sure I'm explaining that well...
Not good enough at it yet to build anything fast, but I could see that being the case after a few more months with it.
VCL is still the tried and tested UI framework for Windows only applications though, nothing beats its flexibility.
<input id=foo></input>
<input id=bar></input>
<button onclick="sum()">sum</button>
<div id=result></div>
<script>
function sum() {
result.innerText = parseFloat(foo.value) + parseFloat(bar.value);
}
</script>
That's full of "bad practices" but for the use case you're talking about, who cares?Instead they whip out React and because native browser elements apparently are the devil they add tailwind/material design/bootstrap/whatever on top.
Once you do it that way, the web approach honestly ends up as complex or worse than many of the alternatives...
React projects are just as susceptible to that, and "modern" web development is quite frankly a larger maintainability headache due to the dependency hell they bring.
For example, this is a simple visualizer for different numerical integrators that I wrote in a day or two for a college course: https://scleox.github.io/integrator-visualizer/index.html. The the source code is just one single html file: https://github.com/SCLeoX/integrator-visualizer/blob/master/...
https://html.spec.whatwg.org/multipage/form-elements.html#th...
/s
Tcl/Tk would be the most straightforward choice. Even easier than Lazarus. It's not really a native look, but practically nothing is truly native these days.
Java with Swing does still exist and works too.
It's harder (IMO) to "scale" a Tcl/Tk or wxpython project though as there aren't great built-in patterns and especially with wxpython, the API is a bit clunk and boilerplate heavy.
For a bigger project that you don't need to be cross-platform, you can still make a Windows Forms C# project in Visual Studio. It still works pretty well even, although Visual Studio seems to get slower and farther from this use case each year.
As the GP said, FP / Lazarus.
There are plenty of resources and new books being written. You can find a collection at https://learndelphi.org
Free edition: https://www.embarcadero.com/products/delphi/starter
Another person had the same experience. https://news.ycombinator.com/item?id=24582890
How dare you.
At some point they extended the RTTI information so that you can also make dynamic calls to methods, obtain fields, etc so the RTTI data became larger.
Lazarus adds a ton more data to the executables so where you'd get a 1MB in some recent Delphi, you'd probably get something like a 5MB executable with Lazarus (without debugging information - that'd make it much larger) on Windows. On Linux it can be even larger, e.g. the simple calculator shown here[0] (up left window) is ~2.88MB, stripped.
In a way Delphi is kinda similar to how Unreal Engine works whereas Glade is kinda similar to how the original Quake engine worked.
My main problem with delphi: it is "too proprietary". It was a very productive ide in the 90's or early 2000's but lost their path and never recovered.
Some new versions broke compatibility with previous version's components. There was the case where you paid a good amount of money on some proprietary components and they simply wouldn't work in the next version: you were imprisoned in an obsolete ide. By not being multi-platform (I hear it improved it lately) you could only use it with/for win32 so it lost servers, embedded and mobile. By not being open-source nobody could improve it.
Then it had to compete with "native tools". Whoever develops for windows wouldn't quit ms' tools to use it, whoever develops for mac wouldn't quit apple's tools to use it, whoever develops for android wouldn't quit google's tools to use it, whoever develops for linux was mostly ignored after kylix.
Note that I didn't even mentioned price and license.
They improved it later, I heard. But seems more like the old case of too little too late. Most successful programming languages today are open source and multi-platform. Delphi was dependent on win32 for too long and it still is "too proprietary". You do the world a favor by porting your project to lazarus.
Give me a good cross platform GUI. Give me a good IDE for it. Don't make me learn yet another fucking programming language that exists nowhere else to use it.
The last part counts against this and also against Flutter, which forces you to learn Dart which is used nowhere but Flutter. What would have been wrong with Go or TypeScript? People already know those.
Most successful languages are open source for very clear reasons, but a cross platform IDE is something that could very well justify being commercial. It's an absolute ton of work and a constant moving target to support. So far no pure open source effort has managed to succeed unless you count the various HTML-based GUI systems that are indirectly subsidized by Google and Apple.
Rapid application development is not an empty promise here.
All my other endeavours with UI programming (Java/Swing, HTML/JS frontends, QT) felt way less productive. Maybe MS C# is the closest to Delphi nowadays.
Delphi is really from a different age, simpler times, when the common paradigm was having the app directly connected to some sort of SQL database, which serves as a stable, static data source for the UI. Making glorified database editors is what it was really good at.
These days.. things changed. UIs need to be flexible, reactive, reusable, adaptable. UIs that can handle uncertain states, asynchronous data flows, change dynamically and so on. SwiftUI / React / Flutter all ended up at the same paradigm, it's a much more advanced way of doing things. Also, high level languages are much more pleasant to work with.
That's not my memory at all - even web-based traditional ASP apps made it relatively easy to use WYSIWYG form editors that modified the code as needed. But expectations around how dynamic UIs are supposed to be have changed. SPAs in particular are not very amenable to auto-code generation, but supposedly some options do exist (retool? Haven't tried it though).
Delphi still delivers unmatched productivity when it comes to designing UIs and writing maintainable multi platform software.
Delphi's FireMonkey framework has a lot of things right and you can create resusable forms easily, where you don't have to fight with a declarative UI (This paradigm is an anti-pattern and totally misplaced for UIs).
There are many multi platforms apps made with Delphi which are by no means "a glorified database editor" ;)
Turbo Pascal, Turbo C, Delphi, C++ Builder were all very innovative products that catered to the individual developer. The Embarcadero rebrand seems like a turn towards Enterprise.
For me now, JetBrains is the new Borland, a scrappy company with a strong focus on what individual developers need and consistently turning out excellent software.
Also Embarcadero isn’t Borland. They acquired Borland’s product lines but not Borland itself.
You need the $1,200 compiler suites to make the real cash.
They had an offshore team that theoretically could work with the codebase, but I don't remember seeing anything of consequence added to the product in the past 7-8 years. If I ever found that they bought out a company that used technology that I depended upon, I'd migrate to a new solution.
I can't bring myself to use it.
The "free" version has a hook in it that just doesn't sit well with me... they want a cut of any money I make with it, on their terms. It's easier for me to ignore it, and just put up with the limited documentation of Lazarus. I miss the days when I could afford Delphi.
I actually miss the days of Windows desktop development. Good Times.
3+ years of consultants and meetings but not one line of code so far :-)
(Oh, you already did that? ;-)
In the old days I loved them. Then I found myself using older versions despite having newer ones because of important bugs.
Then came 64 bit code. They were years late in releasing a compiler that could produce 64 bit code and the reaction from the company seemed to be that it's a tiny portion of the users that need it.
Never mind that for that not-so-tiny portion (you might have no direct need of 64 bit address space but if you have to play nice with 64 bit code you have to be 64 bit--plugins) it was a total showstopper, companies relying on it were dead in the water, had to to a total rewrite or die.
I got the strong feeling that they were looking at us customers as a resource to be milked, not supported. My employer at the time died in the housing collapse, while I still have a couple of little Delphi apps around that I wrote I haven't touched it since then. C# was almost as good (and at this point all that's missing are arrays with an enum index and arrays that don't start at zero) and has much better support.
Windows Forms is C# and borrows heavily from Delphi's Rapid Application Development (RAD) style.
While I have long moved on from Pascal, many great ideas of Delphi live on in C# and Typescript.
C# needs .NET which has its very own circle of dll hell with compatibility and confusion version numbers for your users.
The Embarcadero website experience for a developer is nonsense. The first thing you see in the page is "BUY NOW", "FREE TRIAL". It's so aggressive that my instant reaction is to close the product page before I even get to see what the product is about.
And no, I don't want a "product demo". I don't want to contact sales. I am a developer I don't care about that. "Contact sales"/"Request a product demo" sounds intimidating. It sounds like you want me to spend $5000, which I am not willing to spend.
My primary objective as a developer is to develop applications. The website has to focus on assisting that process.
...On the part of the Turkish Ministry of Education, which figured out that they'd get legions of young programmers all primed to jump ship to Free Pascal / Lazarus?
Naah -- smart, but not exactly evil. :-)
(And VS of that era was rather meh...)
VS Code isn't.
The closest i've seen elsewhere is QtCreator littering the code with red error messages about the unknown symbol while i'm typing the code together with a lightbulb next to the line with it which, if i click on, it adds the #include.
From a technical perspective the ability seems to be there, it just doesn't feel as smooth and seamless. Not to mention all these errors that appear while i'm typing make me anxious - like, STFU, i know the code is wrong, i'll fix it once i finish typing this part :-P.
The vega/buran strain of ransomware malware comes to mind as a well known example from the past few years [1]
[1] https://www.acronis.com/en-us/blog/posts/meet-buran-new-delp...
And recently lots of malware detection has started looking for that "weird" ABI signature, so now everyone's anti-virus is throwing up alarms at perfectly legit age-old software just because it's built with Delphi.
It is basically open source and cross platform Delphi (there are a bunch of differences but from a high level perspective i think that it describes it fine for people who already know Delphi).
Also check this video i made a few years ago[0] making a simple puzzle game in Lazarus. You can skip to 11:30 if you don't care about downloading, compiling and configuring it and just want to see it in action.
You can do the same with Lazarus without any external libraries. I wrote a fairly polished production system for a seafood factory in Lazarus 15 years ago which is still in daily use.
Amazing what a single developer with the right tool can achieve, shame we cant get any young people interested in anything but apps.
It was a tiny software group in a large company, and paying Embarcadero whatever they wanted was just a matter of filling out paperwork. I imagine a lot of their current paying customers are in a similar situations.
At a recent meetup in my country, 90% of Delphi developers were over 60 years old. Also, Embarcadero licenses aren't cheap.
One would likely argue that JetBrains probably isnt a RAD IDE, but Visual Studio definitely is fully capable of RAD editing capabilities, think WinForms.
Update: Looks like JetBrains is $149 per year, and moving forward after October 2022 it will be $173 per year.
Company was doing well from it, but trying to scale, and finding anyone to code delphi was impossible.
Tldr; it's a similar experience to vb6: drag n drop controls into a form, edit their properties and write code for their events...
Then comeback here and tell me your answer. I will tell you in advance mine: "In Delphi it would take maximum 3 hours". That's the core definition of RAD.
It was so beloved because it actually worked exactly as the marketing slogan at the time claimed: "The power of C++ with the ease of Visual Basic". (Or was it the other way around?)
This was a time when Microsoft's "Visual" Studio IDE was anything but: It had no visual form builder, just a code editor. To actually put something on screen, you had to write reams of code straight out of a Charles Petzold tome. Visual Basic, OTOH, sure did have a nice easy graphical UI builder, but a pathetically weak ultra-high-level language -- in contrast to Object Pascal, which is every bit as high- or as low-level as C++.
I learned all three in an "Object Oriented Programming" course I took in 1995, IIRC in the order 1: OO concepts, 2: C++, 3: VB, 4: Delphi (or was it 2: VB, 3: C++?). After the two preceding, Delphi was a revelation and love at first sight.
That love soured slightly after the Kylix debacle, some more with diverse bugginess and drawn-out implementation of Windows developments (Unicode, 64-bit, High-DPI...), and finally petered out almost totally over the covert "feature moved to higher-priced more Enterprise-y edition" and overt price hikes over the years (decades) since, with the on-again off-again free (gratis) Community Edition shenanigans as perhaps the final nail in the coffin.
But Delphi versions 1 through 7 (1995 -- ca 2005-10) still has, and probably will for ever have, a special place in my heart as my most beloved programming tool. And fortunately, it has a worthy heir in Free Pascal / Lazarus.
HTH!
Native AOT will only support command line applications, and shared libraries.
Pity that they decided to kill .NET Native.
Lazarus - "RAD - Rapid Application Development." Embarcadero - "RAD Server - Reduces the complexities of rapidly building and deploying a multi-tier turn-key enterprise REST API application server with Swagger support."
What does RAD refer to? What is it actually?
Rapid Application Development :-P.
Wikipedia has an article[0], but in general it can probably be thought as a precursor to agile (the article says that agile is a RAD method) in that instead of doing some lengthy pre/planing process you use an iterative approach that adapts to what the users want.
In this particular case Lazarus is a RAD IDE in the sense that it allows quick development and iteration of functional GUIs - Delphi was also like that but at some point Borland/Inprise/CodeGear/Embarcadero/Whoever made it more of a name to use for their products ("RAD Studio") than something that describes them.
[0] https://en.wikipedia.org/wiki/Rapid_application_development
The debugger situation has slowly been improving but there is a unification of using LLDB for all platforms.
I have fond memories of Pascal, it's the language of the first programming class I took.
But yeah. The website and the screenshots do not inspire confidence.
Signed,
Sid Dabster