I love the idea of a WYSIWYG IDE that's integrated with the language like this, or like VB used to be, but personally I just can't stomach the whole "have to learn yet another language to use it" problem. From what little I've played with Lazarus and FPC it seems really nice though, and I might make use of it for some smaller projects at work in the near future. I'm sick of trying to make web apps and all the ridiculous nonsense with that process.
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.
Learning another language, if you've already learned a few, it's a very small cost if the other benefits are big. After all, many of use learned some of the languages we learned because of the benefits that came with them.
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.
I don't disagree that learning new languages is relatively easy, I know a bunch myself already, it's just that to use a language very effectively you have to be able to think in its terms and that requires some time investment. Fluency takes time.
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.
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.
> 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.
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.
As I view the problem, what's lacking is a GUI markup standard roughly comparable to HTML. HTML browsers were not originally meant to build full-on GUI's in, but the industry has accepted the habit of forcing them to "do" GUI's using convoluted tricks and giant JavaScript libraries.
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.
If the "industry" adopts them as a standard, then they could take off (and if not encumbered by intellectual property lawsuit risk). XUL also looked "too Webby" to me, closer aligned to HTML than desktop-like GUI's.
I'd beg to differ, XUL produced very clean native UI yet accepted styling with CSS years before I'd seen anything else like it. At the time I was writing Firefox addons and I was blown away but what I could do with it vs. WinForms or somesuch
FYI, XUL is being kept alive by the Pale Moon/Basilisk team, who has created a next-generation platform based on XUL called UXP (Unified XUL Platform).
Some part of the industry did; in MS shops a lot of XAML is used. The old MS would've pushed XAML for web applications a lot more, but the new is more of whatever the developer wants. There are people working on XAML everywhere (all platforms including web), especially in the Xamarin.Forms camp, but there is no force or adoption there. It's mostly WPF (and a bit of Xamarin) that uses XAML, but that's a large group still; I encounter it everywhere at partners/clients (usually Java runs on the servers 'in the basement' and some non trivial amount of WPF/Xamarin.Forms (XAML) (now with .NET Core where possible; even the .NET only shops do seem to like it) runs on the front facing systems).
Interesting. Thanks. On first impressions QML looks more suited toward multimedia applications than CRUD or business applications. But, we can test that theory...
So, instead of language bindings for the UI builder, you need an in-language implementation of or binding to a client for the GUI markup language output by the UI builder? While I like the idea of a generic UI markup languages, it sounds like you've replaced the problem you want to avoid with a bigger one.
Generic GUI API's that fit a wide variety of application programming languages has proven a very tricky task. I know of none that do it close to right.
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).
I would say that Rebol did this very well with their builtin VIEW DSL. You can effortlessly build a very complex desktop app in this manner. If you scroll down a little bit you can see a lot of simple GUI apps like paint that require nearly zero boiler plate.
I think there has been a big miscommunication somewhere. I don't see what IDE's have to do with this. I'm thinking of say having a "draw button" command that works in any programming language similar to how just about any programming language can send and receive HTML to "have" a UI via a web browser. But, the markup language would be better suited to GUI's than HTML/CSS/DOM.
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.
Not really, as you only need to implement handling for the messages you actually care about and you can pass them through, say, a file descriptor. Just like UNIX commandline tools do. You could handle that in a bash script.
I thought this was obvious but apparently my phrasing was confusing: I meant that on a personal level. I personally would have to learn Pascal as I only know a tiny smidgen of it right now.
Indeed, Object Pascal in Delphi 6 had blazing fast compilation (for various reasons not least it's unit system), like click and it runs a half second later on a 250,000 line codebase.
What's the reference speed for golang or generally a quick compiler on contemporary hardware? My own experimental non-optimizing compiler compiles >1M lines per second, and it's not even optimized or multithreaded. Currently quite happy about that :-)
The original Turbo/Borland Pascal compiler was a single-pass compiler written in assembly. Not sure if they ever rewrote it in a high-level language. The small, simple grammar helped, as did the unit system. With Delphi, linking became the most expensive stage of compilation.
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.
If I am not mistaken, later versions of Delphi removed the restrictions on declaration order.
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.
I stopped using Delphi after version 4, but I was curious, so I did some googling. Looks to me like forward declarations were still needed in Delphi 2010, at least for class declarations: https://stackoverflow.com/questions/2137030/cant-get-a-forwa....
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+}
I think one of the reasons why new languages are going for compilation again is the death of the multi-architecture ecosystem. Support x64 and ARM and you can play with the big boys.
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...
I've got no idea why Microsoft was going apesh· for bytecode all of a sudden.
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.
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.
I can't find anything in the post you link that supports your conclusion. The author seems to be a person from the research area, in the team for F# maybe?
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.
We were able to do multi-architecture with compiled languages just fine.
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.
> We were able to do multi-architecture with compiled languages just fine.
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.
I felt the same way but I tried playing implementing a quick idea in Lazarus last year and I swear it was the fastest ramping up I've ever had. Pascal/Delphi are a little weird but I found them easy to pick up.
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
Back in the days existed a Delphi-like environment under a scripting version of Delphi, with a very close match of the IDE (it borrow all the controls of Delphi). it also have a VB dialect!
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).
> 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
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:
One issue versus WYSIWYG editors for the web is that you can't simply absolute position everything. The design need to be "responsive" to all screen sizes!
Its funnt how people will not want to use Pascal of any flavor because its perceived as old/obsolete and yet the same people have no problem firing up AWK to solve a text processing problem.
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.
It's the aesthetic ("program", "procedure", "begin" and "<>") and the association with proprietary software (Borland) that make Pascal feel "uncool".
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 :)
Wikipedia provided this simple description, which would be nice to see on the RC post (but perhaps they assumed the only folks interested in an RC post would be folks familiar with the tool already):
Lazarus is a free cross-platform visual integrated development environment (IDE) for rapid application development (RAD) using the Free Pascal compiler.
I miss WYSIWYG IDE's like Delphi, VB-classic, and Lazarus. Dealing with HTML "autoflow" and Bootstrap is a royal pain. You sketch a draft GUI that seems a good fit for the application and users, and then realize you have to jump through hoops backward on a unicycle while chewing gum blindfolded to get it right on web browsers. Jetsons WYSIWYG technology yanked from my happy fingers by an LSD "standard". (I'm assuming "office" applications here, not those needing smart-phone UI's.)
I cut my teeth on VB classic, as I'm sure a lot of folks my age did. I was learning C/C++ concurrently, got through the basics, and of course hurried to GUI programming since that's what I made. It's been 20 something years, but I remember it being something like 31 lines of code to just get an empty window in Windows. With VB it was basically zero effort. I wish WYSIWYG IDEs for both desktop programming AND html (remember frontpage, or hotdog?) would make a comeback in a big way. To this day I shy away from GUI programming because of how tedious it is.
Yeah, me too. They were one of the steps on the pathway of enabling users and blurring the line between user and programmer. Sadly, the industry lost interest in personal computing in favor of turning users into a resource to farm and feed to advertisers.
Since it's more income to bill for rocket science than bicycle science, there's no incentive for many to simplify UI standards. Right now we are stuck with "rocket science" web-based UI's and JavaScript brain surgery.
Don't get me wrong, HTML browsers are fine for most documents and document navigation, but don't scale to real GUI's easily.
Since we're talking web and not native, your metaphor works only if your "rocket science" is performed with used swimming pool materials and your "brain surgery" with gardening tools.
HyperCard > VB-Clasic > Delphi... Then that's it. Somehow we stopped there. Our Computing Speed might have grown 1000x but We somehow manage to put in additional 1000x complexity to cancel out.
Not only have Software development not gotten any easier, most software are slo lots more resources intensive.
Hmmm, can Lazarus be used to build a "GUI browser"? For example, can one send a "create button" command or tag to it and have it draw one dynamically? What about new panels and forms? How "meta" can its GUI engine be at run-time.
Yes, it may be able to. At least, Delphi, the idea (and language) of which Lazarus is based on, was written in itself, at least for v1, I've read. Probably for later versions too, because Object Pascal (although IIRC the language is now called Delphi, like the product), is a powerful general-purpose programming language, with OOP support, module (units) support, and even some sort of generics (IIRC) in later versions.
Can you recommend any documentation on the "meta" angle? Most documentation I find assumes the creation of "static" widgets that are activated or hidden at run-time (or at least act that way).
Heeeey, but actually, unicycle is real fun! Sorry for being OT, but I couldn't resist :D it's just that this exercise you mention seems as a seriously fun idea for one of the many unicycle trials competitions :) just I'm not sure if the chewing gum would up the challenge in any way? That said, I wouldn't really compare JS fighting as similar to really fun unicycle tricks ;D Again, sorry for OT :D
Sorry, didn't mean to offend unicycle riders and jugglers. It was just an analogy about having to "juggle" (coordinate) many tricky activities at the same time.
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 ?
Indeed. GUIs should be laid out visually, by hand. Because that's not tedious, and everybody has a display with the exact same size, resolution, and aspect ratio, right?
WYSIWYG web tools still exist, but they went SaaS. They’re called “low code development platforms”. If you want to play around with one you can download mendix’s modeler for free.
Can I interest you in a very Delphi-like IDE for building web apps with nothing but Python?
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!
Don't know if it is you specifically, but anvil.works comes up in these contexts a lot so for once I'm going to give you some feedback: anvil.works is not the same thing.
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.
Nice product but it may have been better to release this as a opensource product because there will always be a fear that if your company goes bottoms-up, those companies who used your platform will be left high and dry.
The thing is, making Anvil open source now would virtually guarantee that outcome.
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.
What about releasing it like how Node.js was released? that is a full web platform but one which uses Python instead of Javascript? and with a repository for packages which people can download and use or even contribute to?
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.
That's my fear also. Emulating GUI's in web browsers takes a ship-load of code. Therefore, it needs strong maintenance prospects to safely last into the future.
If you released this as a node.js type app which can be run directly on the user's desktop and accessible via the browser for some setup functions and via an editor like VSCode etc for the source code editing, this could be a great product.
Hi everyone, I just want to encourage anyone who is on the fence to give Lazarus/FPC a shot.
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.
I was eyeing Lazarus, because it is close to my particular crossplatform toolkit ideal. I think that UI toolkit should use native widgets and near zero cost FFI. So any toolkit that draws for itself is not within my ideal. The most problematic platform for my ideal is Android as the toolkit should run without NDK. C++ does not cut it. Java would work for Android, but on other platforms there's FFI.
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.
> But memory handling is something that does not fit my vision.
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).
> But memory handling is something that does not fit my vision
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.
Re: I think that UI toolkit should use native widgets and near zero cost FFI.
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.
FWIW LCL (Lazarus' framework) emulates the Windows behavior (there are even some reimplementations of Windows functions in non-Windows platforms to assist with that) since the API "descends" from Delphi's VCL which is Windows-only (and IMO it makes perfect sense that if you need to emulate some OS's behavior to focus on the most popular one).
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).
Making it fit every OS well is indeed a tricky task. Perhaps the option of using native widgets can be given. Actually, ideally there'd be 3 choices for developers: 1) A default single uniform style for a given widget(s), 2) Emulation of OS-specific styles, 3) Native widgets. But providing all 3 without making a mess or bloatware is easier said than done.
The tricky thing about cross-platform UI dev, when considering macOS, isn't just about the widgets and so on. It's things like placement, hierarchies, etc. Like you said, easier said than done. To demonstrate for those who aren't sure:
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.
When it comes to the controls, etc it always wraps them, but the exposed API is based on VCL which has several Windows-isms and those Windows-isms are replicated to other widgetsets. One example would be the reliance of several controls (like toolbars, lists, trees, etc) to image lists (which is basically a Windows Common Controls thing that is used in Delphi - Lazarus just keeps the API but reimplements those common controls). On a lower layer, LCL widgetsets implements several Windows API functions (often accessed via the LCLIntf unit or the widgetset itself as methods). As an example this file reimplements several of Windows API functions in Gtk2:
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 made one that consumed the HN API a little while ago (maybe a year?) using the fphttpclient library bundled with Lazarus. It was pretty simple to use and all the documentation is on the wiki[1]. It is a lot more low level than I am used to personally but it was fun nonetheless.
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.
I created a small app to read the Epicor ERP api from freepascal. Fast and simple. Did it as much to refresh my pascal knowledge as to show others that it should not be ignored as a language. As a language is very rich and more cross platform than most others. Lazarus is a cinch to create a GUI that you can then cross compile for other platforms.
Indy is one of the more commonly used networking libraries. It’s open source and in active development (with few breaking changes). Works for Delphi as well as FPC. I’ve had great success with it for FTP, HTTP, POP3, and SMTP.
I just recently loaded it to make a simple prototype application with it and it was a smooth and easy process. I still hesitate to fully do a big project with it in almost 2020 (I was proficient with Delphi 20 years ago). But if you leave the tech-coolness factor aside, Lazarus is a powerful tool.
Free Pascal has come a long way. When I first messed with it, it lacked generics even though Delphi supported them. Nowadays I can compile Delphi code with generics just fine.
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 don't think I personally would want to use Delphi in this day and age
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.
Oh yeah, single static binaries are awesome. I think it's one of those things that helped make Go super successful as well.
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.
I feel like Go sits in a very similar space to FPC. Go has a bigger runtime but does a good job of polishing the overall language semantics to be GC-favorable without being GC-centric. FPC is more mature, though, when you consider the large number of Delphi libraries, generics support, etc. Both of them have a much less complex build story than a C++ project since they have actual module support.
There are lots of similar apps in use in industry and they can be the final step to improve a workflow. There would be more if we could get a Lazurus-in-Python with a build to static binary system.
Similar case here where I work. There's a Delphi 3 application with an access database that has been in use for an unknown number of years. Last update to it was in 2002 or 2003 and it's been in read-only mode since 2005.
> When I first messed with it, it lacked generics even though Delphi supported them.
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).
Something I always wondered about - what's the current state of affairs wrt Gtk and Qt support? Both are available (different versions, even!), but which one is preferred, so to speak?
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.
Gtk2 is the most mature one, Qt4 follows next (and AFAIK you can build it for Qt5 too but never tried it myself) and Gtk3 is in very early stages. Gtk1 might still work too, but the only distro i know that ships Gtk1 is Slackware.
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.
I installed it a year or so back for testing, and I find it especially telling that you still have to download three independent disk images (compiler, GUI, extras).
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.
Some years ago, I had to write program that extract a foot pressure platform for an orthopedist, and I had to do it with a closed-source Delphi API.
Delphi was already old at that time and difficult to find.
I though about Lazarus and it works perfectly with the Delphi blob file.
It's a very great tool.
Ah, good ol' Delphi ... Sweet memories ... (A former user of Turbo Pascal, Delphi and C++ Builder here.) For some desktop applications, using Lazarus is most likely fine. For a wider adoption, it needs a rich(er) set of VCLs and a seamlessly integrated way to build modern Web applications. Just my 2c.
It is viable just fine as it is, i'm not sure what you have in mind.
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
I think most people, certainly me, who would be looking for a Pascal compiler are trying to avoid C++ like the plague.
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.
Yet, it would be good to have an open source alternative to C++Builder. In other words, besides Pascal, to also have an option for a mainstream [native] language.
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.