Lazarus 2.0 RC3 – Delphi-compatible cross-platform IDE
forum.lazarus-ide.org
forum.lazarus-ide.org
One wonders why we don't have a more generic form of this sort of thing. And no, I don't mean the various "GUI builders" that are out there that produce code you then have to merge with your program, or an XML descriptor that you have to parse with your program, because those are still specific to having bindings for your chosen language.
There really isn't a reason I can think of that I shouldn't be able to throw together a GUI in a WYSIWYG editor and maybe define some basic behavior, then give it one or more programs it should run in the background and pass messages back and forth. Or even let me just tie events to a command pipeline and dump the result into another widget, basically just letting a GUI be part of the composable toolset following the UNIX philosophy.
In a lot of ways it feels like a forerunner of C# (unsurprising as the lead on Turbo Pascal/Object Pascal was Anders Hejlsberg).
I loved Delphi 6, still miss it in some ways.
Java AOT solutions were all commercial (gcj doesn't really count) and .NET had NGEN, but it was only meant for fast startups.
.NET was specially disappointing in this regard, given that it had quite some influences from Delphi.
We had to wait around 20 years for AOT to start being part of the default toolchains.
Had it been there from the start, including proper value and unsigned types in Java, and maybe there would be much less software written in C and C++.
Turbo Pascal 5.5 had an advertised compilation speed of 34 000 lines/minute, on 1989's hardware.
http://edn.embarcadero.com/article/20803
So something like PC 386 running MS-DOS 4.x, real mode with 640KB, eventually 1MB, if making use of highmem.
So excuse me for not being that amazed with Go's compilation speed achievements. :)
Part of being single-pass was it hardly did any optimizations, and of course declaration order was completely rigid. Back in the 1990s there were competing commercial compilers like Stony Brook Pascal that did optimization, and at the time there were optimizers that you could run on the .exe files, but for the most part people stuck to Borland's tools.
I spend a good part of the 90s writing fast 2D and 3D graphics stuff, including a commercial game, and performance was never an issue, especially as Object Pascal supported embedding assembly blocks seamlessly into your code.
I am with you on performance for graphics stuff, hence why I never bought into stuff like disabling bounds checking on the whole application is a must for performance.
Borland's Pascal compilers did have a way to disable bounds checking locally, with a special compiler directive comment: {$R-}. It took effect from where you used it, so you could do:
{$R-}
for i := 1 to 10 do
writeln(myArray[i]);
end;
{$R+}
Thanks for googling it.
Back then? Intel was barely considered mature, every Unix manufacturer (including sun) had their own processor architecture, and who knew what was coming out for the smaller devices ("thin clients" were all the rage).
I still think that for those scenarios Sun should've stuck with PostScript, and we still might have C/C++, but would be spared JS/HTML/CSS.
I've got no idea why Microsoft was going apesh* for bytecode all of a sudden. Especially considering that they had the heads of Modula-3 and Delphi...
Delphi probably was one of the main reasons. It was a lot better for Windows 32 development than VB and there were projects to port it to Linux.
Microsoft then recruited Delphi leads, settled a long running suit with Borland (with the fallout of stopping Delphi for Linux development) and finally created a platform where they keep control, unlike native API that is much more open.
COM Runtime was going to be native (Ext-VOS), but then they decided to go VM path and .NET was born.
https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net...
If you read Don Syme blog entries about .NET history, you will see a few similarities with WinRT.
Just with .NET metadata instead of the old COM type libraries.
So the double bet on COM since Vista was a bit like WinDev's revenge.
However how things turned out, it appears DevTools is having their way again and even .NET Native might be redone post .NET Core 3.0 release, as per Q&A session at Connect() 2018.
Who do you think had more weight in the decision, this guy or the chief architect for .NET that came from Borland? Of course Java was the model for the VM thing, but that's the what, not the why, the reason they, in the words of the gp, went apesh··· with the bytecode thing.
Actually I can neither be in the mind of whoever made the call, just make an educated guess, but at least it has a base on facts that I was paying attention to at that time.
Don Syme is one of the researchers responsible for .NET and the implementation of .NET generics. F# was a follow up project on his career.
What Java had going for it, was being free (beer), more stable across OSes than a mix of K&R/ISO C, pre-ISO C++, batteries included libraries with GUI support and endless amount of money thrown out by Sun, IBM and Oracle driving adoption (yes they were into Java almost since JDK 1.0).
As for .NET and bytecode, see my neighbouring comment.
Indeed, we can even distribute them all in the same package on some systems (like NeXT). Here's an idea: have an OS that guarantees support for a certain bytecode VM and format for binaries that supports multi-arch. Now developers can compile to native and the bytecode, so even any unsupported arch will still be able to run the application with just some additional overhead. Now your OS can be distributed for new and experimental archs and still be usable because people's favorite applications will still work.
Sure, you can do that, but you need a protocol/interface/API between the GUI and the program(s) it interacts with, and then you need to either manually consume that in the language those programs are in or have a library that handles the interaction, and the problem ends up being essentially equivalent to language bindings directly to the API.
By the way, the "GUI markup language" doesn't necessarily have to be XML-only. Maybe JSON or CSV versions can be defined also. However, XML is a good start: learn to walk before you run.
As far as how interaction and screen changes could be handled, see: http://wiki.c2.com/?GuiMarkupProposal
I particularly dig the 3-type "update" technique that uses "Attribute", "Tag", and "Delete" scope. (It's about half way down in the document.)
Data structures and object models vary too much between languages. If you "solve" this by extracting out anything potentially programming-language-specific (such as variable types and data structure "types"), you end up with something that looks like a markup language anyhow (or at least a declarative data/attribute language).
Note I am not against middle-ware that can translate a GUI markup language to and from "native" data structures/types. I use and make "HTML helpers" in specific application languages all the time so that I'm not communicating in raw HTML for specific common items.
https://en.wikipedia.org/wiki/XUL
https://en.wikipedia.org/wiki/Extensible_Application_Markup_...
RIP XUL, you died too early
I think will be smart to build a Delphi/FreePascal renderer with an API to make easy to embed into other languages (like with TCL).
I sketch some of the idea in https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh...
Delphi/FreePascal integrate very well with C APIs so I think the glue could be easy.
I think that's how the editors in Plan 9 support extensions/plugins/scripting by exposing parts of the editor on the filesystem.
Something with FUSE might do the trick, though mounts are always tricky. Kakoune supports JSON RPC over a fifo, for example:
https://github.com/mawww/kakoune/wiki/JSON-RPC#input-keys--o...
Then again my very first programming experience was in VB so I might be biased :)
If anything is wrong with it, I'd say some of the widgets are little out of date or lacking, but since most of that maps to GTK primitives it's only when you need something weird that you might have to start hacking, since there probably isn't an open-source tool lying around like we'd be used to with JS/ruby/go
Many of us graybeards already know Pascal though. Some even used Delphi and C++ Builder in their heyday, and remember it fondly. It was basically the only sane alternative to VB, with better productivity (instantaneous compilation, even on hardware from 20 years ago!) and a real programming language behind it.
I learned Java because of the promise (long ago) of write one run anywhere. I learned Ruby because of the promise of Rails. I learned Go because of the promise of fast and single-file-executable (maybe not the best reasons, but those were my excuses :) ). Etc.
How hard can it be to learn Pascal? Is that really a frustration or an obstacle?... If I were making desktop apps, I wouldn't care what language it was as long as I could quickly make cross platform GUI apps that did what I needed.
You've seen code written in language X before and been able to instantly tell it was ported from language Y, right? It's the programmer equivalent of a literal translation from Chinese, where the words are English but none of the metaphors, euphemisms, or subtle connotations are accounted for.
And it isn't even like I have something against Pascal, it seems better designed than C and is just as mature, but I don't really want to invest the time needed to gain fluency at this point in my life. And when I think about that, I wonder why I should need to for this kind of functionality.
LAzarus provides a great way to address the perception. Fast, free, rich language underneath. Im about to start using in my hobby IOT stuff, but as other posters have pointed out, it works great for Enterprise level stuff as well. Single exe executable is, in my books, a huge advantage.
FTR have started looking at nim as well which seems so far to be bit of a pascal 'reborn' and it also compiles down to single executable. I recommend people look at both if you are needing to distrbute software without the normal installer drama.
Bottom line i believe there is no software silver bullet. Each language has pros and cons and the biggest challenge these days is choosing the appropriate one to use.
While Awk, like C, Is Unix™. Timeless, classic, already there, and cool. This is absolutely just subjective crap, but this is how most of us unix-heads feel :)
Lazarus is a free cross-platform visual integrated development environment (IDE) for rapid application development (RAD) using the Free Pascal compiler.
Nothing magic. Create it, set properties.
https://anvil.works has a WYSIWYG visual designer, with Python for in-browser code as well as server-side. (We compile it to JS.) It's even got a built-in DB if you want it (Postgres-backed). Everything in one language, full front-to-back autocompletion...all the things we missed about Delphi!
The market has spent the last few years demonstrating that the sustainable number of large companies whose main product is open source is...One. (Red Hat, if you were wondering.) Even trying to become that kind of company requires a highly speculative VC-fuelled trajectory, which is famous for turning sustainable 100m-scale companies into 1% unicorns and 99% rubble.
Even Docker, which utterly transformed its target market, is barely making any revenue ($25m/year on a $1.3bn valuation). All its value is busily being subsumed into Kubernetes, itself a loss-leader from a company (Google) that makes all its money from something else.
Anvil-the-company is sustainable, profitable, and growing, and Anvil-the-product is getting better all the time, because we charge for what we produce. We would love to be able to give it away and keep doing that - but basically, we can't.
Ultimately unless there is an active and vibrant ecosystem, there is very little reason to consider your platform - especially when there are alternatives like Node.js, Django etc.
Also, for me I will be concerned about how I will integrate Anvil with third-party libraries needed for things like reporting, authentication/authorization, E-commerce etc.
Sure, the GUI wizard is not there for Django but what if someone were to develop such a wizard for Django? or what if someone were to say that it is best to stick with Django / Vaadin/Ketura/.NET/Go/Rocket.rs even if it takes another 25% more time to develop in because the ecosystem is much bigger and we can predict with more confidence that Django / Vaadin/Ketura/.NET/Go/Rocket.rs is going to be around?
HOWEVER, if your product was available open source, is a lot easier to setup and use than Django/Ketura/... (you could provide it as a docker image) and you had a business model where you provide hosting for that solution (similar to Heroku) and/or paid support, you may end up making more money because a lot more people would use your platform - lot more than your current model which very few companies will risk purchasing.
You have some nice looking tooling, but you insist on hosting the result and locking the user into paying rent to use something they built. Your on-prem is locked behind "if you have to ask you can't afford it".
You'd have more interest from people like me if I could just buy or subscribe to your tool and know that even if we eventually drop the subscription the application I produced would still be usable.
But I suspect that your goal isn't to convince people like me, but catch people reading this who might be more amenable to your terms.
Except the insanely fast compile times, native WYSIWYG editor, etc, etc.
Don't get me wrong, HTML browsers are fine for most documents and document navigation, but don't scale to real GUI's easily.
It's not really "GUI programming" anymore. It's making HTML/CSS/DOM act like a GUI.
I've not been working on GUI programming much since, but I really enjoyed the Qt experience; good tools and superior documentation.
I never liked gtk - much for the same reasons as your Windows GUI C programming; Too verbose for trivial and mundane things.
https://www.tmssoftware.com/site/tmswebcore.asp or
https://www.elevatesoft.com/products?category=ewb or
https://smartmobilestudio.com/
All three claim to be a form of "Delphi for the Web"
http://www.unigui.com/explore/what-is-unigui
https://www.atozed.com/intraweb/
This one seems to be also available for Lazarus ! http://www.raudus.com/
I wrote an old desktop app for medical laboratories in Delphi (started with D2 ...) and am still quite unsure if this would allow me to port at least some part of it for the web in an (cost and time ) efficient and secure way ...
Does anybody have some experience really using them ?
...Right?
Not only have Software development not gotten any easier, most software are slo lots more resources intensive.
It's LGPL, there's no company that can take it away, and it generates native binaries without the bloat and garbage of Qt or the mental gymnastics of C++. It's cross-platform native and really wonderful. Give it a try. The community is awesome.
FreePascal does compile to Java bytecode. It is an experimental feature as far as know, but it's promising.
There is lots to like about FreePascal, even if I dislike the syntax a bit. See the Modern Object Pascal Introduction¹ for reference. But memory handling is something that does not fit my vision. I would hope for something similar to Swift - automatic reference counting. I like that the compiler is not LLVM or GCC based. With ARC I can forgive even the manual UUIDs for components.
That's how I saw it from quite a big height so excuse me if I'm misguided.
At the moment Swift looks promising for me without possible transpilation to Kotlin as seen in one project ². Or D, as it should be easier to fit Java. But I have my eye on Lazarus. It certainly is much more mature a project.
If the target audience is cross-platform, that's hard to pull off. Each OS's native GUI engine is too different. Emulating a common target behavior is usually better (until a good general GUI standard comes along). Maybe your particular need is not cross-platform, but Lazarus's goal is.
The end result is obviously that under Windows things work great, under X11/Linux with the Qt (i think both 4 and 5 are supported nowadays) and Gtk2 being generally fine as they mostly behave like Windows (especially Qt) and the worst being Mac support since it is so different from Windows (that and the Mac backend was originally written using Carbon as that was easier to interface with FreePascal and still to this day is the most robust backend for Mac, although in reality both the Carbon and Cocoa backends aren't that great). And of course the programs despite using native widgets, still look like Windows programs on a Mac dress ([0] is an old screenshot from my 3D world editor compiled under Mac, the Windows-isms are clear). You can obviously try to make things look more Mac-y (and i did try a bit) but you need to do so much (and in a different branch since some changes can be very invasive) that IMO isn't worth the effort unless you really want to get that "Mac look" (but be prepared for a lot of custom code and changes to bypass LCL).
Say Joe Bloggs wants to make an alert window to confirm if the user wants to save the document, but needs to add custom text and graphics so can't rely on a default implementation on each platform. So he makes an alert window, looks great.
Except his design is utterly confusing for macOS users. See, on Windows (and plenty of Linux environments), the Save and Cancel buttons would be centred on the window, and Save would be at the left. On macOS, Save and Cancel would be aligned to the right, and Save would be the right-most button.
Okay, so that's a pretty easy thing to solve with a cross-platform toolkit. Instead of defining the placement of buttons, you just define the text and action for the default button, the text and action for the cancel button, and they'll be put in the right place for every platform. Easy.
But that's such a small example. Try scaling that to the way macOS and Windows/Linux differ in the use of view hierarchies. Windows-style tab controls vs NSTabView; Windows/Linux-style tabbed, left-aligned settings windows vs standard macOS-style centre-aligned preference windows with NSToolbar at the top; each window/section of an app having its own menu bar as opposed to macOS having a static menu bar whose items enable/disable depending on context; MDI vs document-based apps; the fact that macOS apps can still be running even with no windows open, meaning that certain parts of the UI can still be opened, and your UI must account for this despite another window that you would expect to be open (on Windows or Linux) not being in memory at all.
To an engineer, these might seem trivial or not that big a deal. To a user, that's potential data loss.
https://github.com/graemeg/lazarus/blob/upstream/lcl/interfa...
Note that all widgetsets implement these methods, even the Win32 one (which instead of reimplementing it just forwards the calls to the real Windows API).
I do Delphi a lot of years (still remain as moderator in http://www.clubdelphi.com) and can say that is easy to just. Is much easier than use obj-c and the idioms around the language make things simply. Is the only language I have tried with manual memory management that I found simply to follow
P.D: Help a lot strings are refcounted and you can refcount some stuff if desired.
Note that in practice memory management is almost never an issue with FreePascal since a lot of things are based on TComponent that provides an ownership-based model and dynamic arrays (at the language level) handle a lot of cases you'd need to worry yourself. Of course if you create raw objects you also need to release them, but this is something you generally do in constructors and destructors.
> I would hope for something similar to Swift - automatic reference counting.
I'm not sure how i feel about this personally since i think it adds a lot of hidden baggage to the language, but you can use reference counting using "COM" interfaces (the name is just a historic artifact, they work in non-Windows environments too) in current FPC. There is also work to allow any custom type become reference counted by defining some special operators (essentially functions) that the compiler will automatically call to incref/decref/etc (which can also be used to implement RAII).
> With ARC I can forgive even the manual UUIDs for components.
Is the manual UUIDs you are talking about in Swift? AFAIK you do not need to define any UUID in FreePascal (except for the COM interfaces mentioned above).
Some months ago I had a need to create a "quick and dirty" API utility for internal use and I remembered about Lazarus.
However I couldn't find an HTTP client component that I could use. I just wanted to do the equivalent of a curl GET/POST call.
I'm not sure if maybe I'm not familiar enough with the wiki structure so I missed it, but I remember I searched for about an hour before I gave up.
I'd really like to start using a Delphi-like IDE again as I think it is a very useful and productive tool, especially for ad-hoc stuff.
Any pointers in the right direction would be greatly appreciated!
I do remember I clicked on that briefly but I thought it was too low level like you said, and I thought there would be something else so I kept looking.
I guess I was wrong, but it's good to know there is something that works.
It also doesn't look that bad anyway, so I might as well give it a try.
Thanks!
`
discogsJson := HttpGet('https://api.discogs.com/artists/45/releases?page=1&per_page=...');
`
Here: https://github.com/synopse/mORMot/blob/54dd708d25586008260f2...
I don't think I personally would want to use Delphi in this day and age, but there's still a lot of useful Delphi/Pascal code out there and it's great to be able to use it on Linux.
I totally understand where you are coming from, however I must say having everything compiled into a static-binary is a powerful thing that we often overlook today.
Case-in-point: Around 2007 I was consulting for a manufacturing facility, basically doing accounting system programming. Their warehouse department needed a small app that basic did two things (a) Check to see if a invoice was marked paid so they could ship, and (b) Record the Fedex / UPS tracking number back into the accounting system.
This was something that was meant to be added into the main accounting application and installed into the warehouse, but there were the usual practical issues (the PC that existed in the warehouse was an under-powered Win XP machine that couldn't actually run the accounting system, so a new machine needed to be purchased...basically weeks of time were required to solve it, but we needed a solution ASAP).
On a whim, I whipped up a simple single-dialog box "utility" in Lazarus / Pascal that would check if accounting had released the invoice and then record the tracking number. Literally took me maybe 3 hours to download, program, test, and deploy.
A few months ago I ran into the product owner from that consulting gig so many years ago....after catching up a bit, asking what had changed...he sheepishly added "I've still never got around to incorporating your warehouse 'utility' into the main program yet". I said 'surely its still not that old WinXP box?' and he said no they had upgraded a few times and just copied the .exe over each time and it continued to work.
Obviously such a simple 'utility' app is not a great example of why you would choose to use a language / platform, but it is a testament that what it does well, it does well. My 3 hours of billable time amortized out over 12 years now was a really good ROI.
If Go had a RAD, well, it'd be very enticing to me. Sadly they have only touched on UI a little. If you want to write something with Win32 API it's not too hard and there's plenty of good libraries, but sadly there's no VCL equivalent. I'd like that.
I guess in that sense Lazarus is still useful. But, I don't find myself needing a RAD too much. What I would've used a RAD for I find Python + Qt to be usable enough for.
Unless you mean in the "delphi mode" specifically (which i'm not sure how it handled generics support), this isn't true since Free Pascal introduced generics support before Delphi did and sadly when Delphi introduced generics they decided to make them incompatible with Free Pascal's syntax (which i personally prefer since it is more explicit).
I've noticed that e.g. Debian installs the Gtk version of Lazarus by default, if you use the virtual package. But it's not clear whether this is a conscious choice, or it just dates back to when they only had Gtk.
AFAIK Gtk2 is the preferred one for shipping since it is still widely available and you can simply give a binary (Lazarus uses a rather old version of the Gtk2 API by design so that it is compatible with almost every Gtk2 distro out there, including some that are a few years old). Qt4 and Qt5 require an intermediate shared library that provides a C API and Pascal bindings for it and in addition Qt4 is removed from some distros.
Even sadder is the fact that instead of having a regular Mac app bundle, the installers spray things all over the filesystem. It’s defensible for the CLI tools, but hardly native.
Still, I look forward to final release - I just hope it has a better native look and feel than 1.8.
In any case C++ support for Lazarus is almost impossible due to the work needed and the projects that will need to cooperate - i go into details here: https://news.ycombinator.com/item?id=15893362
It’s funny when you read about languages like Rust and Go basically trying to undo decades of C-induced damage, reinventing (albeit also exceeding) thangs that Pascal/Modula/Eiffel already had.