Lazarus – A Delphi-compatible cross-platform IDE | Hacker News Reader

Lazarus – A Delphi-compatible cross-platform IDE

lazarus-ide.org

236 pointsJack4E4B181 comments

I mentioned Lazarus in other threads a few days ago (since my kids are playing around with it) and it's great to see it as a top-level post. Some random thoughts:

- It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app (besides RealBasic/Xojo which I've yet to try - was put off by their mandatory registration)

- I wish we had RAD environments like this for more languages (Racket, Python, etc. - even JS).

- On the Mac, installation is a bit fiddly. It needs a little polish and support (a standalone, integrated bundle would be better, or at the very least a unified installer).

- We've been retrofitting web UIs to desktops to such an extent (I'm looking at you, Electron) that the tiny, supremely efficient apps Lazarus spits out put the last couple of years into stark perspective (2GB RAM used by Slack, etc.)

I love Lazarus, and hope it helps resurrect the RAD approach for other languages - if anyone knows of any similar environments (besides QtCreator, etc.), could you share the links?

I've not used Lazarus or Delphi, so I can't really compare properly. Perhaps I'm missing something. But:

> if anyone knows of any similar environments (besides QtCreator, etc.)

Why "besides QtCreator, etc"? It sounds to me almost like "do you know any X besides all of the popular X". Is there any particular reason you discount QtCreator? Does it not work for your purposes? Or is it just a case of you already know about it and want to hear about more obscure tools?

> It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app

I've found Qt with QtCreator to be an incredibly productive way to develop desktop applications. Both old-school QWidgets-based Qt with QtDesigner (the RAD portion of QtCreator for pre-QtQuick) and QtQuick/QML with and without its RAD interface.

> I wish we had RAD environments like this for more languages (Racket, Python, etc. - even JS).

I've used the Python version of Qt with QWidgets in the past and it was a pretty nice workflow. I've never done it personally, but I know of people who use Python + QtQuick/QML and seem pretty happy with it. There's also various "app builder" tools for JS, but I don't know how good they are.

There is https://blind.guru/qta11y.html as a problem with QT, I think it made to HN like three days ago.

Whether or not that is a negative point for Qt depends on your perspective. I mean, Qt never claimed to have JAWS support and the guy is free to submit a patch. Its unfortunate, for sure, that Qt doesn't support popular accessibility tools, but that's hardly a problem unique to Qt or open source tools. This "If you want to support users with disabilities, you probably should not rely on hippie coders right now" is unfortunately true for most open source tools, but also for many commercial offerings. Does Lazarus/Delphi fare better with accessibility and JAWS support specifically?

Also from your link: "For now, you will need to write a native UI for every platform you want to support." -- is the Lazarus/Delphi story any better in this respect?

The discussion you mentioned is here, btw, and it seems to have mixed views: https://news.ycombinator.com/item?id=14946358

> Does Lazarus/Delphi fare better with accessibility and JAWS support specifically?

For this particular issue, yes, because Lazarus uses Win32 for Windows applications. For Linux it uses GTK2 (can also use Qt instead) which AFAIK has good accessibility support. For Mac OS X it uses Carbon (there is a Cocoa backend but it is still in prealpha) so... it depends on how accessible Carbon apps are i suppose.

I don't think there is any special support for accessibility however, it is all about what the underlying widgets provide out of the box.

Apparently GTK2 doesn't fare better with JAWS: https://stackoverflow.com/a/4136662/1495627

That isn't relevant to Lazarus though since - from what i can tell from its site - JAWS is a Windows-only program and Lazarus uses the native Win32 controls under Windows. So it should work fine.

As a Delphi/FPC/Lazarus veteran (10+ years), comparing one of the quickest compilers with Qt/Boost C++ development cycle looks like a joke. Much faster edit-compile cycle which scales without issues up 1e6+ LOC (yes, modules/incremental compilation done right right from the start)

The Python bindings to Qt don't require compilation. QML is an interpreted gui declaration, and Qt Quick allows programming behavior in Javascript.

You are not comparing apples to apples.

Try finding any native code static typing compiler with RAD on board featuring quick compilation within 2x C++ resulting binary speed.

Not apples to apples, but its a pretty good tradeoff for C++ IMO: you get super high turnaround times because the bulk of the UI tweaking cycle is in QML or the RAD tools and you only need slow-compiling-C++ where native performance is required.

For me, while I like fast compile times as much as the next person, its not a deal breaker -- the workflow/environment and library features are. Ie can they easily deliver the required value to my customers. QML gives me a good middle ground between productivity & quick turnaround time, native integration and native performance. If you're unwilling to make that tradeoff, well... then you're limiting yourself to the tools that don't make that tradeoff (which may be perfectly fine, of course).

It's not a good trade off for the end user. As it's not native you end up with a much slower running application with more memory overhead and bloat. Lazarus is compiled to small native applications that are easily installable for the user, fast, with both small memory and disk space usage.

I say this next piece as both a developer and an end user; developers of desktop applications are getting out of hand with how they treat these things. We are now to the point where a large segment of the developer population has so little regard for the end user that they believe bloatware Electron solutions are a good choice for "native" text based chat application.

> As it's not native you end up with a much slower running application with more memory overhead and bloat.

For Qt that's just not true: you can reach 1080p / 60fps fluid animated UI on small embedded boards such as raspberry pi's. All the rendering is done using a nifty OpenGL pipeline.

To clarify, I was referring to the language choices here. Comparing Lazarus as opposed to Python in the particular case, as well as referring to even worse performance on Electron/NodeJS.

I certainly was not intending to imply that Qt is not performant as it certainly is. Qt is the default UI for Lazarus applications as well, but it does support other UI toolkits (such as Tk) out of the box.

EDIT: reading your reply to sibling comment, I think I probably misinterpreted what you are referring to here so my below response maybe is replying to the wrong thing.

Regarding your first paragraph, Qt/QML performance is very, very good, memory use isn't insane (in my personal experience at least), rendering is solid 60fps and animations are ultra smooth. Maybe Lazarus is better, but not being a good tradeoff for the user, at least in Qt's case, just isn't true.

Regarding your second paragraph, I completely agree, it those are C++ developers using frameworks like Qt doing that. They're primarily web developers who are using what they're familiar with (JavaScript) to develop desktop applications. An Electron application is very different from a Qt application.

Even with QML, which uses JavaScript, the bulk of the Qt framework is written in C++, the declarative QML is compiled to a scene graph on load, the rendering is done in OpenGL and shaders, and any heavy lifting or performance sensitive code can be done in C++ (Qt makes it VERY easy to call C++ from JS and JS from C++). Typically only non-performance-sensitive glue logic is in JS. This is very different front Electron and Qt (even with QML) is still primarily a C++ framework.

PyQt is nasty GPLv3 or commercial license only. (And no, PySide is not an option: their last stable release is years old and for Qt 4.)

Because QtCreator isn't up to the job compared even with Delphi 1 for Windows 3.x, but sadly the younger generations never got to use it professionally.

Delphi and Visual Basic, were like the Smalltalk/Lisp Machine (I am exaggerating a bit) of the RAD programming generation.

Try to create a database frontend or image manipulation program in QtCreator just with the GUI designer.

The UI part of a database frontend is trivial and the code is very minimal in Qt (but there still code involved, for sure).

An image manipulation program, what does Delphi provide out of the box for this? I would assume that if you have anything non-trivial, you'd have some custom code to write? I mean, they can hardly have built-in components for every possible use case so I don't have to write any code. What am I missing here?

> I mean, they can hardly have built-in components for every possible use case so I don't have to write any code. What am I missing here?

The eco-system of companies selling components for every possible use case.

Most VB/Delphi shops would get early licenses from such companies. DevExpress is a surviving company from those days.

https://www.devexpress.com/Products/VCL/ (over 210 controls)

So you had a huge toolbox full with components for the majority of enterprise most common use cases.

As far as I am aware, there aren't any company selling components for Qt.

There are, but they're few and far between and certainly not as diverse as what you've described.

> Why "besides QtCreator, etc"? It sounds to me almost like "do you know any X besides all of the popular X". Is there any particular reason you discount QtCreator?

I know Lazarus (almost) inside out and i've tried several times to use QtCreator, mainly because C++ would allow me to reuse some of my C code. However i could never get used to how QtCreator expects from me to do more stuff, how unweildy the laying out widgets is (this is natural since Qt's layout management was made expecting programmers to do layouts via code but compared to Lazarus' alignment and anchor based layouts they feel like taking a step back - although the same can be told with Lazarus' layout if you try to do it via code) and other not necessarily big issues but still annoying enough for me to always drop it.

Have you tried QtQuick/QML? It sounds like its anchor/grid/constraints-based layouts work very similarly to Lazarus.

QtQuick, on the other hand, uses non-native widgets - the whole thing is rendered as an OpenGL scene.

True. Some people may find that as a deal-breaker. Personally, with the age of web-UI's (that look very different from each other and certainly don't look like the native widgets), I don't see QtQuick's native-styled-but-non-native widgets a problem (and the OpenGL-based system has proven to be really great for performant animation).

But I can see that if you require platform-native widgets, QtQuick is probably not an option. I just think that most people don't need this ;-)

I'd argue that at this point, if you're building a desktop application, one of your goals is probably going to be the use of native widgets, which could be for e.g. accessibility concerns. Else you might as well build a web application.

> Else you might as well build a web application.

The reasons to use something like Qt instead are many:

  - While the widgets aren't platform-native, they emulate the native look and feel, so look a lot more native than your web application. Yes, yes, you likely won't have the accessibility features, so if that's a concern (which it probably should be), sure, Qt and other such libraries won't help. (Note that even MS don't use their own "native" widgets in, eg, Office and Visual Studio, so even within first-party windows applications, you lose consistent look and feel)
  - Battery life. A C++ Qt application typically uses much less battery than a similar web application. This may or may not be a concern.
  - Smooth animation. QML's OpenGL-based widget rendering has incredibly smooth animation support (and its super easy to add to your applications). Anecdotally, much nicer animations than I've ever seen in web applications.
  - Platform access or native libraries. Even though your widgets aren't native widgets, you might still want to manually access platform features or C/native libraries. While some web-applications-in-a-webview tools do allow you to do this, Qt makes it trivial since you can drop down to C++ with ease. With conditional compilation, you can even make this work cross platform.
  - Performance. Sometimes you have requirements that simply require C++ performance. Many industrial users of Qt, for example.
  - Qt is also used for embedded UI's where a web application may not be feasible.

My point is that there are many reasons why you might choose to use a toolkit like Qt for desktop applications even if you don't need native widgets.

Isn't that a JSON-like language? I find describing UIs in text instead of "drawing" them like done in Lazarus to be going backwards.

Although TBH i haven't really looked into that. Most QtQuick programs i've seen look like something you'd see in a mobile phone or tablet instead of a normal desktop application, so i didn't had the incentive

You can do a lot of things graphically : http://blog.qt.io/blog/2017/05/24/qt-quick-designer-qt-creat...

> Isn't that a JSON-like language?

It is (but its actually good!), but QtCreator also has a design tool to visually create QML-based UI's.

> I find describing UIs in text instead of "drawing" them like done in Lazarus to be going backwards.

This is a preference thing I guess - some people prefer visual design tools, some prefer text. I quite like QML's approach of giving me a simple declarative text description language and then providing me with a visual design tool to author it with if I prefer to do so.

> Most QtQuick programs i've seen look like something you'd see in a mobile phone or tablet instead of a normal desktop application

Early QtQuick was very much like this, but nowadays it has pretty good platform-style emulation (QtQuick Controls). How many applications use it, I don't know, especially nowadays that QtQuick has iOS and Android support. Also, since it gives you full styling freedom, I guess (for better or worse) many people make use of them rather than trying to look native. I've seen some very non-mobile style QtQuick applications too though, including desktop mail clients and such and they looked great.

> Qt's layout management was made expecting programmers to do layouts via code

what ? no.

For widgets: http://doc.qt.io/qt-5/designer-layouts.html

For QML: http://doc.qt.io/qtcreator/quick-screens.html

You misunderstood, i meant that the programmers who designed Qt's layout systems expected the programmers who will use Qt would prefer to write code for laying out their UIs (most likely because this is what most UI libraries did and still do) so they designed the APIs with that in mind. I didn't mean that Qt required from them to do it via code.

This is in contrast to Lazarus' layout system, the programmers of which expected ("assumed", "thought", "believed", etc) that the programmers that will use Lazarus will create the UIs using the IDE's UI desiger and so made the layout system be more UI friendly as opposed to code-friendly.

I want more tools. Qt is popular and I've tried it before, but it keeps cropping up as "the new RAD" in these discussions and I was (unsuccessfully) trying to steer the discussion away from it.

X rough, python no not-bad native widgets, Qt not well designed(@see blog don't use Qt, G)

You're saying that Qt is not well designed because it's accessibility support does not include certain apis needed for the JAWS screen reader? That's a very narrow definition of "not well designed". I personally find Qt 5+ with QtQuick (not the older QWidgets) very well designed and I've looked into a large number of GUI frameworks over the years in a variety of languages.

"It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app (besides RealBasic/Xojo which I've yet to try"

If you're interested in Basic programming then Gambas might interest you. Although not a clone of VB, it can be roughly considered being to VB what Lazarus is to Delphi: a 100% Open Source implementation. I would prefer Lazarus anyway, but it's indeed nice to see different alternatives to proprietary dev systems.

http://gambas.sourceforge.net/en/main.html

I remember one BASIC, called RapidQ, which I really enjoyed playing with a long time ago (which was freeware, but unfortunately I think it stopped being maintained as the source was sold to another company).

It had a rather cool graphical interface to create GUIs, kind of like VisualBasic I think.

It even had APIs to interface with DirectX.

Pic of what the IDE looked like: http://basic.mindteq.com/Screenshots/RapidQ.jpg

That project looks pretty cool actually. It is unfortunate that it is not cross platform.

As awesome as Lazarus appears to be here, Rebol is even more amazing in my opinion. There is no designer, but the GUI DSL is mind bending. Red is a Rebol inspired language that is also tiny with a compiler as well so you can build a nice cross-platform-native GUI and distribute it as a tiny executable (~1.5 MB). You can see the GUI stuff for both Rebol and Red. There's a YouTube video by Nick Antonnacio (spelling) that shows him building something like 40 GUI apps in an hour ranging from email apps to games like tic-tac-toe and snake...it was pretty crazy to see the first time.

I'm checking out Lazarus currently.

Do you mean this: https://youtube.com/watch?v=D50XULVZaYY ? Looks nice!

That one and this one:

https://m.youtube.com/watch?v=lR5Fzv6DP0I

That guy can build some simple apps FAST! It helps that Rebol has built-ins for everything.

Very cool, the examples that he builds are very similar to what I've built when I stated in Delphi (simple chats, word processors, music players) but to course Rebol is much more concise. I wish the controls would look more "native". Currently they look like Windows 3.11. Also... Downloading code over plain HTTP? Not good idea...

For people that are interested, here's a free book: http://www.lulu.com/shop/olivier-auverlot-and-peter-william-...

The new language Red is 98% Rebol compatible and uses native GUI feel. If only it'll get finished and reach 1.0. Still a bit left on the roadmap.

Sounds good. Would you recommend learning Rebol and then Red or just forget about Rebol and start with Red? Not 1.0 means it's not production ready?

Now, if it can spit out Android apps :-)

Speaking of the bloated slack client, there's a new native desktop app for Slack, Skype, and many others:

https://eul.im

It's only 4 MB and uses ~100 MB RAM.

Do you know who's behind the project?

I am :)

Right now I'm working on setting up the company.

Wait, how are you doing Skype?

Kamelåse så fedt. Sykelkugle!

I recently tried out Lazarus, and besides looking a bit dated, it works REALLY well. I had no Pascal experience so it was also overwhelming for a hello world app. But after the basic Pascal "Hello World" command line app, a GUI app didn't even require a tutorial to get working. Really impressed and am considering Pascal for a project.

For me as for the guy who only look at Lazarus not as developer, but as user who just go to compile map editor of our game (developed by other very skilled developer) main frustration was multi-windows interface.

Not that I can't understand why some would prefer to work in that mode, but that alone make it feel more dated than it's actually is. It's still weird why they still ship it in multi-window mode by default, but fortunately all you need to do is install "anchor docking" and then it's become a lot more usable for guys like me.

Also ability to patch and recompile your own IDE on the fly without waiting for half of hour to it to compile is just great. Nothing like that is possible in case of 99% C++ projects.

> main frustration was multi-windows interface.

Multiple windows are very comfortable if you have multiple displays connected to your computer.

Lazarus is basically a Delphi 2 clone. Delphi ditched the multiple floating windows design starting in version 3 and every subsequent version has been the more traditional "MDI" design similar to Visual Studio. I really like that Lazarus kept the floating window design because it's nice to be able to see your desktop, the wallpaper is more pleasant than whatever solid color background is on the MDI client, and you can access tools and things by just clicking through to your desktop icons. Lazarus is like the best version of Delphi frozen in time.

This isn't true, Delphi 4 definitely had the multiple windows setup

But you could disable it. The multi-window thing was something Delphi lifted directly from Visual Basic, and even VB dropped it (well, more like it got swallowed by VB.NET and Visual Studio.)

With monitors getting bigger we can abandon the multi window way and embrace something better, but surely not MDI which to me is even worse. Tiling is the answer: a giant single window containing the entire application, and a layout definition stating what section appears where and at what size (read: area percentage). Options to maximize the active area can be implemented, but the goal should be freeing the user from being forced to find and move windows from below other windows or partially gone out of the screen.

I think Visual Studio has the right idea with being primarily MDI but then all of the various windows can detach and float to other screens and wherever. I think if Windows would just render your desktop background on the MDI background instead of a solid color that would be a nice system setting.

I think maybe Delphi 5 was the first version where it stopped even being an option. I remember 3 was MDI and I'm surprised I never bothered looking for the option to switch it back.

The floating windows were still very much present in Delphi 7, my preferred arrangement [0]. D7 was the last "good" version before the .NET era. Actually I remember the buzz around Lazarus and Free Pascal really growing when the .NET versions of Delphi came out. So I think its fair to say Lazarus took plenty of influence from versions later than D2.

[0] http://i.imgur.com/gHQR6aH.png

oh dang I used D7 for years and didn't know you could configure it into this mode. I would've preferred it at the time.

I'd say clearly Lazarus is tracking the best of Delphi, not just version 2 from 1995.

It's been years since I worked in Delphi regularly, but I still have it installed and have been looking around in it this evening for the first time in a long while. Right now I can't find the option to change from this to a single-window mode, but I'm not sure there is one.

I think the trick is to just not run it maximized, then undock the various parts from the main editor window. Then once you have things resized and placed where you want, you save it as a Desktop layout. I don't know how far back that feature goes.

I would have to reinstall it from scratch somewhere to see how it looks by default. I really want to do this and dare say I even intend to! I may even have D5 and D3 somewhere in a box too, but now I'm approaching self-promise overload!!

Here it is maximized and docked. Is that something like what you remember?

http://i.imgur.com/aeTYPjb.png

it's a real blur but I do recall doing the unmaximize and undock stuff to get things looking just right. I distinctly recall no longer being able to do that in some version.. I thought it was 5 but you've proven me wrong. maybe D2005?

I'm pretty sure that was the default mode, I never knew you could not have windowed mode.

Agreed, it seems that the odd-numbered Delphi versions were the best.... 3, 5, 7. 7 was my main environment for years.

Those are the versions I had. It seemed to parallel the odd numbered Windows versions too, or at least that every other version was decent.

Ah, but you only see the desktop if you have no windows other than Delphi. The moment you do, those windows start getting in the way and distracting with their content.

I do have two monitors and understand multi-window mode has it's uses, but for any person who used to [name standard IDE] it's frustrating first impression. It's basically gives false sense of complexity to the tech that actually easy to use.

Lazarus/FPC checks so many nice boxes:

[x] Statically compiled

[x] Native UI on Linux/Mac/Win

[x] Typically compiled without code changes on Linux/Mac/Win

[x] Small binaries

[x] No GC

[x] Readable, somewhat python-like syntax

[x] Still, doesn't rely on indentation for nested blocks

[ ] (Fill in)

do you know what UI kit is used on Linux?

There are options for both GTK and Qt.

Very nice, I will take a look.

As soon as you need 3rd-party libraries "statically compiled" is no longer the case. Or at least it's not easy, depend on platform and still bring a lot of mess.

Though in the right hands Lazarus is a great tool since relatively complex project could be completed just by one developer. E.g here is our game engine map editor:

https://github.com/vcmi/vcmi_editor

Another thing to note is that FPC provide good performance and even used for game development and memory footprint is small. There is RTS on Steam called Cossacks 3 and it's fully in Pascal (though no idea if they using FPC outside of Linux):

http://store.steampowered.com/app/333420/Cossacks_3/

PS: Another example would be open source Hedgewars of course.

I've created small projects in Lazarus and you are right in all points except in the small binary part, also I would add that it comes with db drivers for Postgrees, MySQL and Firebird SQL out of the box.

Depends on what you define as small but if you remove the GDB debugging information you can trim down your binaries by a huge amount. My last project was 3.4MB.

Back in the day I used to run the exe through and get them even smaller: https://upx.github.io/

UPX is misleading though since it needs more memory than the EXE itself.

If you compare to the "modern" way of building cross-platform apps: Electron ... with its 100s of MBs, I'm definitely regarding Lazarus binaries as small :)

Electron is degenerate, not "modern". XUL was modern.

No GC is actually an advantage? The world really changed, there are people rejoicing for procedural languages, while we have so many excellent OO and FP alternatives, and they are actually happy to shoot their own foot with manual memory management. I'm not really sure that the change has been for the better.

Lazarus is Object Orientated. Delphi definitely offers garbage collection in newer versions, not sure about Lazarus.

No. Delphi offers reference counting, but only on interface variables. It's a huge difference really, because if your last interface variable that points to an object goes out of scope, the object is freed from memory. Even if you have raw class pointers to it.

Example:

    IMyInterface = interface
        procedure Foo;
    end;

    TMyClass = class(TInterfacedObject, IMyInterface)
        procedure Foo;
    end;

    procedure TMyClass.Foo;
    begin
        WriteLn('Foo');
    end;

    procedure DoTheFoo(AObj: IMyInterface);
    begin
        AObj.Foo;
    end;

    procedure SomeMethod;
    var
        LObj: TMyClass;
    begin
        LObj := TMyClass.Create;
        DoTheFoo(LObj);
        LObj.Foo; // <-- Will cast nil pointer exception,
                  // as object was freed when AObj in DoTheFoo went
                  // out of scope
    end;

I work with Delphi in my day job.

Oh, in that case that's no better than C++'s shared_ptr.

I remember Delphi being fun back in the day and it still compiles way faster than C++, but C++ is evolving and maybe with modules even the compilation speed gap will disappear...

I actually feel that shared_ptr is a better fix, because that makes the memory handling consistently opt-in, instead of inconsistent.

I highly doubt it's production code. Nobody uses both objects(pointers) and interfaces simultaneously. It's a quick way to disaster. In practice Delphi/FPC interfaces serve their purpose.

For those lacking CS background, reference counting is an GC algorithm.

The 5th chapter from "The Garbage Collection Handbook", http://gchandbook.org/, one of the most renowned books in the field, there are of course other equally renowned sources I can refer to.

Formality aside, it's about deterministic GC vs nondeterministic GC.

Reference counting isn't deterministic in the presence of large complex data structures.

You will know when memory gets deleted, but not how long it will take, nor how much stack space the destructors will require to run.

Enjoy Herb Sutter's "Leak-Freedom in C++... By Default." at CppCon 2016, where he explains how those issues affect C++ and goes on to implement a tracing GC.

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

Swift also does Reference counting, the difference is huge. Speed of code is in another level. I am new to Lazarus, but I am guessing they do the same as Delphi.

You would never code the SomeMethod like that, you would use this instead:

    var
        LObj: IMyInterface;
    begin
        LObj := TMyClass.Create;
        DoTheFoo(LObj);
        LObj.Foo;
    end;

> [x] Readable, somewhat python-like syntax

I have a rather different opinion on OP that it has a needlessly verbose syntax.

Pythonic it is definitely not. Even C# (which is another creation of Anders Hejlsberg, after MS poached him from Borland) has a better, readable and concise syntax.

I used to be a Delphi evangelist in it's glory days. Now I bristle when I read Pascal source code, there's so much unnecessary visual noise. Of course if your brain is habituated enough to parse Pascal code, eventually you will tend to filter out the begin..end's.

Pascal syntax belongs to C family of language.

As regards to Python-like syntax, I think you are referring to the Nim language, whose syntax happens to be similar to that of Pascal.

My feeling as well. In my heart I am really happy that Lazarus (and Harbour, the Clipper-compatible compiler) exist, but being rational the days of desktop applications are over.

Python is being run on microcontrollers these days; I actually wrestle with the non-adoption of Python (or Ruby, or Javascript, or Tcl) as 1st-class citizen language for desktop and mobile; it does not make sense for me. Certainly writing desktop/web apps in C++ or Pascal make even less sense.

Perhaps I am forgetting the big number of fellow developers that work on ERP systems and outdated software, for them it is a blessing to have free tools, while in the 90s such a tool could cost $3k.

> My feeling as well. In my heart I am really happy that Lazarus (and Harbour, the Clipper-compatible compiler) exist, but being rational the days of desktop applications are over.

Oh boy, I hadn't heard about Harbour until now; earlier today I was looking at the Wikipedia page for id Tech 5, and it says it uses Clipper so I was really scratching my head wondering how they pulled that off and why. Now I know, thanks for mentioning it. :- )

Wait. Why would a 3D game use Clipper? What for?

That's what I was wondering, I'm thinking of tracking down whoever added that to the Wikipedia page, because I don't know how they found out.

I very strongly suspect that some confused person (or algorithm?) saw that that the level design tool Radiant has a "clipper" and ran with it.

https://en.wikipedia.org/w/index.php?title=Id_Tech_5&diff=pr...

Hard to say, bots usually have usernames, so probably a person.

https://en.wikipedia.org/wiki/Special:Contributions/99.100.1...

They also seem to have added a similar section to the id Tech 6 article, it's possible they're just an insider.

https://en.wikipedia.org/w/index.php?title=2015&diff=prev&ol...

But looking at other edits from this address it sees like they might just be a vandal; or at least somebody who is very confused about how Wikipedia works.

Just you wait edge computing will move a lot of power to the client... it's coming, especially for AI, cars and any intelligent device.

If someone is working on ERP systems then I don't think the cost is going to be that significant to them.

> Python is being run on microcontrollers these days;

So does Pascal and its descendent Oberon, including FPGAs.

https://www.mikroe.com/mikropascal/

http://www.astrobe.com/default.htm

Natively compiled to machine code, safe, without any help of C.

> there's so much unnecessary visual noise

FWIW, I took over maintenance of an in-house application written in Delpi/ObjectPascal, with practically no prior experience with Pascal (but one fun weekend looking at Ada), and I had almost no problems reading the code that were caused by Pascal's syntax. It might be because the guy initially wrote the application did a good job, but I found the code very easy to read.

Ex-Delphi developer (10 years) - still do some maintenance...

The verbosity is an indicator that it does not require a huge cliff of learning to understand the syntax. (It also means the compiler can absolutely fly, which Delphi did.)

I like the conciseness of later language structures, but they all need to be learnt in order to read or write in them.

The only solution to the verbosity of Delphi was to increase your typing speed or use an IDE add-in that provided shortcuts :)

So I suppose my argument is that the syntax is not needlessly verbose. The verbosity helped the speed of compilation by the simplicity of its grammar, and the learnability of the language is quite speedy as a result of fewer grammatical options.

> Pascal syntax belongs to C family of language.

It can't possibly, seeing how it predates C.

There are specific differences that set them apart, too. For example, the fact that Pascal has statement separators rather than statement terminators (and using a separator in a terminal position is usually an error, e.g. before "else").

Pascal rather belongs to the Algol family of languages, together with C. Algol-60 is where "begin" and "end" come from.

One of the main points that makes me happy about Pascal syntax compared to some C-family langs like Java is that types are placed AFTER the variable names, making it much easier to scan the left border of the editor for meaningful info.

Happy that recent languages like Go and Kotlin have learned the lesson and are going the Pascal way again.

> Even C# has a better, readable and concise syntax

C# has amazingly easy-to-read syntax, but maybe I'm biased because I'm most comfortable with C-like syntaxes.

[x] Easy string handling (compared to C)

I like how you say python-like syntax... as so many borrow from Pascal

I would love to switch off Delphi, but I'm heavily dependent on spring4d which is Delphi only right now. I may build some smaller programs or utilities in Lazarus.

I've made the mistake to write a complex project in Free Pascal. As far as I can tell pretty much every release of Lazarus is breaking something. And surprisingly often those breaks are major (like e.g. broken multi-threading, broken-strings, ...).

For me the whole thing looks more like a playground for hobbyists and is not really useful for anything productive. There's not much continuity in the language. And for the devs something like 95% compatibility seems to be good enough.

For small projects it might be ok to use, but you better keep your snapshot of the compiler locked in a safe place.

On the other hand: If you're young and want to make history as the guy who replaced all those begin/end in pascal with smileys: This project might be your chance...

I like your comment. It highlights what misses from so many discussion about languages/tools down here. Being expressive, powerful, compiled, interpreted doesn't matter much if long term stability, reliability, backward compatibility are not a top goal for the devs.

The same was for Delphi, but no one complained in such way. Your sources were to update accordingly, or you simply remained on previous version, which was not a bad thing, because it is your app, it was working yesterday, why would it break tomorrow?

For new projects you took new libraries.

Personally, I don't like the modern idea of autoupdated anything. Once program is tested and deployed, only cherry-picked (or backported) security updates must be applied.

I have had best success by using the (very stable) version provided in (X)ubuntu LTS, which I'm always staying with, so I'd say it is about finding a good strategy for version selection.

Your project was probably doing something wrong or weird since the Lazarus and Free Pascal developers have gone to great lengths to avoid breaking backwards compatibility - i have code from 10 years ago that compiles almost without changes. The only change that i have to do is when i abused strings as byte buffers that wouldn't work in Free Pascal 3.0. However that was something the FPC developers said for years and they made several release candidates so that people can report back issues. Even then the change was simply replacing all uses of `string` with `rawbytestring`.

The only backwards compatibility breaking they do is when they are fixing compiler bugs that shouldn't be used anyway. For example at some point it was possible to take the address of a property getter and this usually worked, but not always. They changed that to be illegal (according to the language reference it was illegal anyway) so any code that relied on that would need to change (a simple change would be to make a new property or function that gave back the address of the private reference and mark it as inline so that you wont get any performance penalty).

Personally i am very anal about backwards compatibility and i have abandoned tons of libraries (SDL, GTK, Qt, etc) because of that. In my experience Free Pascal, LCL and Lazarus are among the most stable frameworks to the point that they prefer to keep unnecessary things around for years just in case someone is still using them or introduce unnecessary options for the framework to change behavior in case someone is still relying on the old one (this is why for example you get a `RequireDerivedFormResource:=True;` line in new projects, older projects wont have this line which affects the behavior of how forms are created).

Obviously i don't know what your project was doing but you don't really provide any description (both of the issues you mentioned i haven't encountered), so i put my counter-experience here since i wouldn't like people to get the impression that Lazarus doesn't care about backwards compatibility. For me it is a prime example of a very complex project doing backwards compatibility right (hell, the Lazarus IDE itself can even be compiled with Free Pascal compilers that are years old just in case someone might for whatever reason - like the few cases mentioned above, or use FPC from some Linux distribution that only has old versions - be stuck with them). Things that break backwards compatibility are considered important bugs and are fixed - sometimes even at the cost of getting things "right".

Broken multi-threading, broken string, ... Care to elaborate? UTF8 move perhaps? Which native compiler/RAD got UTF8 for free? Virtually every C/C++ project was "broken" in that respect at some point or even now.

I use both Lazarus & FPC from trunk (in between releases) and even then backward compatibility is of top priority to FPC devs.

I work with a multi-mloc application in fpc. We have migrated the code over many compiler versions with hardly any issues at all.

With every update they post a list of things breaks compatibility, and if you are affected, the refactoring tools are almost always enough.

We had two tries at a full recompile migrating from 2.6.something to 3.0.2, and passed all tests within 13 hours of starting the process. (some of the larger stuff were however already fixed since we keep a close eye on the development).

What are you doing with a million lines of Pascal? It sounds interesting!

Btw, OmniPascal for VSCode is also worth a mention as an alternative for quick edits, or for coding those CLI apps in pure FPC. A really nice project, which also helps showing that Pascal is Alive and Kicking :)

http://www.omnipascal.com

(Only issue is Linux support is not (yet) on par with Windows and Mac ... but then, it is open source, so that could change!)

Just wanted to mention OmniPascal :)

What's about Linux support? It's working on all platforms, isn't it? http://blog.omnipascal.com/omnipascal-0-14-0-mac-and-linux-s...

Yes it is, finally :) I like the ability to extract build information from .lpi, despite still needs a lot of work (macros won't work), already lifts the burden to write the unnecessary build scripts.

One of the things I'm excited about, is using FPC/Lazarus as GUI for computationally heavy Go code (Now with the recent efforts to use Go for datascience ... see http://gopherdata.io), now since Go supports shared object (.so/.dll) files.

I collected my (very early) research on it in this thread:

https://forum.lazarus.freepascal.org/index.php?topic=24948.0

... where some users report they tried it already. Seems to work, if not super smooth. Hope it can be improved in the future.

Great news, the key comment there was that Go supports calling from other languages: https://dev.to/vladimirvivien/calling-go-functions-from-othe...

mORMot framework is also a nice example for modern Pascal... https://synopse.info/fossil/wiki?name=SQLite3+Framework

It has DDD, SOA, MVC, ORM (even for NoSql), REST, caching, logging and security features and works with Lazarus.

Looks great - have added to my research list on FPK. Thanks.

mORMot is very full-featured and powerful! I'd suggest to start with its rich set of samples (https://github.com/synopse/mORMot/tree/master/SQLite3/Sample...) and this blog: https://tamingthemormot.wordpress.com/

A bit funny seeing this on here tonight. My teenage daughter was looking to create a native desktop app and I pointed her to Lazarus just today. Then I login and check Hacker News...

While we're at it, for those times when you're hacking on console apps, FreePascal also has a very nice text-mode (TUI) IDE that is basically a Turbo/Borland Pascal 7.0 IDE clone - but cross-platform.

To do that, they had to port Turbo Vision (or rather its open source fork Free Vision). It's still a great TUI library... it's a shame it's Pascal-specific. Would be interesting to have an implementation of it for, say, Python, for system tools and the like.

The Turbo Vision IDE was actually introduced with version 6.0 as an example what the framework was capable of.

It was later available in C++ as well, and there is a port available.

http://tvision.sourceforge.net/

Yeah. I was thinking more like C (with possibly glib as the object model), so that it can then be wrapped in Python etc.

Hoe do you run it?

Even that is a throwback to Turbo Pascal - you type "fp" in the shell (on Windows, after adding C:\FPC\bin or equivalent to your PATH).

Thank you...I'll try that again.

I miss the glory days of RAD

Xcode is a RAD tool at heart so we're in the glory decade of RAD. We just don't call it that.

In my opinion, I wouldn't call XCode the pinnacle. That position is for VB/C#.

Still, things didn't get any more Rapid than they were in 1998 and that's a bit sad. In terms of productivity, C# with WPF/XAML is at best equally good IMO.

WPF/XAML can give you amazing results but I'm nowhere near as productive with it as I was with VB6.

I would venture that WinForms is actually more RAD'ish than WPF.

A lot of that productivity came from the drag-and-drop form editing. And what made it possible (and easy) was complete disregard for any kind of advanced dynamic layouts. Delphi's VCL, .NET's WinForms and the nameless VB6 UI toolkit are all designed around the notion of widgets manually placed on a 2D grid, and the most that you can get in terms of dynamic resizing is "anchoring" their corners to containers.

While true, WPF development when coupled with Blend design can be very expressive.

The main hurdle is getting how templates, styles, triggers and code interact together.

If one happens to work in enterprise projects, it is quite easy to get WPF component libraries.

I didn't call it that so I'm not sure what you're responding to.

That's an interesting point.

However, with VB business users who knew a database would come up with applications that served their needs well.

These applications are still all over many companies and government departments.

In general though, these folks wouldn't be able to do the same with XCode and in addition XCode only targets a platform that isn't widespread in business and government.

IB and EOModeller once too were targeted at business users. The RADsy parts of Xcode are older than VB. It's just a bit of a historical curiosity: while RAD tools went out of fashion (at least for 'serious' programming), Xcode is still ticking away, in mainstream use.

We doing Windows, OS X, iOS and Android development still enjoy RAD.

Perhaps clarification is needed. The glory days of RDAD (rapid database application development). While there is probably something that approaches the simplicity and speed of Delphi's glory days, I haven't found it.

I can think of at least one Delphi developer who went in to management rather than deal with the scaffolding nightmares of current systems. A lot of us followed Anders Hejlsberg when he left Delphi behind and started working on C#. It's very nice, but it's just not the same when working with databases.

I was thinking more VB (that's my background) but I'd include Delphi in that set as well. VB was a pain in the ass at the time but, even as a beginner, it still let me churn out programs at a breakneck pace.

Amen, brother (or sister).

I use Free Pascal at times. In case there are any FP developers here: your build arrangements hamper my use. I tried installing earlier this week from source and could not get it going.

My ideal would be a single configure/Makefile combination in the root directory. Consider if the user does not have root, how are they to set a prefix?

The idea of the 'build' download is good, but not if it needs to link to recent shared-objects. Particularly recent shared objects like libc. Maybe you could put statically-linked tools in the 'build' version.

I guess you need to contact devs to clarify. I regularly build from sources for Linux and cross-compile for Windows both x32 and x64 using just single "make ..." command.

For the FPC/Lazarus project as a whole, it is also good news that there is some work going on to build up a foundation (it exists already), with funding and stuff, to support further development:

https://foundation.freepascal.org/

Among founders being Delphi luminaire Boian Mitov (author of Visuino / OpenWire / OpenWireStudio etc).

Hoping the foundation can take off with some good funding.

I've been watching the foundation since it's creation (I think it's over one year ago), I don't think it has done any significant help to the FPC/Lazarus development so far. Anyhow, such effort is plausible. On the other hand, open source projects like this (http://newpascal.org/) is what actually driving open source going forward.

I wish porting projects from Delphi was easier. I was trying to make Python bindings for the AcBR library[1] and failed miserably.

Shameless plug: if you think you are up to the task and is not too expensive contact paulo at xtend.com.br

[1] http://acbr.sourceforge.net/drupal/

There is another Pascal project out there called Oxygen by the folks at RemObjects. Not free, but I've heard good comments about it: http://www.elementscompiler.com/elements/oxygene/

I'd definitely use it more if I could port over the last few Delphi apps I have in production. My Delphi 7 is getting a bit old...

Aside from single-file executables, the biggest advantage to Lazarus (and also Delphi) [to me] is that all the libraries are also built in the language. No needing to bounce down to opaque DLLs just to display some GUI element.

A bit old is an understatement :^) why not update to more recent iterations of Delphi?

Just in case, I found this: http://wiki.lazarus.freepascal.org/Delphi_Converter_in_Lazar...

For anyone looking for a proper, "modern" introduction to Object Pascal, as found in FPC/Lazarus, don't miss this excellent guide:

http://castle-engine.io/modern_pascal_introduction.html

Do not forget also the tremendous effort in the Free Pascal other big IDE

https://sourceforge.net/projects/mseide-msegui/

It is a pitty dev pascal didn't catch up or ported to FPC.

Looks interesting. What are its advantages when compared to Lazarus?

Smaller and simpler (written in old Delphi, with some 3rd party packages, so Windows only), nothing else I guess. Lazarus is far superior in every other aspects.

Simply not true. Runs on Unix and windows, built on free pascal.

Lazarus is awesome because of the speed of the compiler, the fact that it has a GUI that works, and is OPEN SOURCE.

So one wonders WTH is going on with all the other compiled languages that have nothing like this? And no QT is not the answer, we need a built-in good enough GUI! =)

IIRC Delphi compilers are usually single pass and thus really fast

That is correct and it is why all the variables must be declared before the "implementation" section of a unit. The compilation felt instantaneous.

> we need a built-in good enough GUI! =)

what do you call built-in ?

I see Lazarus pop up on HN occasionally. It's an IDE for FreePascal right? I guess I'll have to open the article again. How are the database drivers? I've been told they're ageing. Is there 64 bit support for Windows or only 32?

There is a Win64 compiler and it's working great! I don't know anything about the database drivers.

Just tested it out and confirmed.

I'm no expert by any means, but I just opened Lazarus to look at the DB drivers and they seem pretty respectable. The MySQL driver only goes up to 5.6 but works well in my experience. I haven't tried the SQLite, Postgres, ODB or MSSQL drivers though.

Also it does support 64 bit, I have a 64 bit Lazarus installed on my Windows VPS.

Glad to know, thanks for the pointer!

As MySQL develops, the bindings are updated as well, but most people will have to wait for stable release. If you use trunk, though, you can enjoy it right away because MySQL bindings has been designed rather easy to port a new version.

FYI 5.6 drivers work on 5.7. not extensively checked but my database application worked fine after mysql was updated..

How do you avoid spaghetti code, in an environment like lazarus?

Discipline. The same way you do in Java and C#. Don't use singletons and global variables.

I'll take this one - architecture.

So you can setup a very standard MVC or MVVM architecture using Lazarus.

I bought this book to help:http://www.apress.com/br/book/9781484222133 it uses Delphi, so there's translation to do, but the concepts are the same.

Also, Lazarus has an amazing community that's a joy to be a part of, and is extremely welcoming.

I'm a hardware jockey (mostly) so if they can explain it to me, literally anyone can get it.

To boot, there are a number of excellent older texts that are just a few dollars, and all the concepts are the same.

There's new material being produced more and more for it as well.

What I'm trying to say is: join us... One of US. One of US. One of US....

That's an interesting question. Lazarus is an IDE like Visual Studio or the JetBrains ones, and it has nothing to do if you write spaghetti code or not, try google "SOLID" instead on that subject.

As someone who maintains a multi-MLOC application in fpc (using emacs and lazarus): discipline.

You don't grow an application to that size by simply building on what might be suitable for a 30kloc application. It requires discipline, experience, trial and error and ability to invest time in properly maintaining the codebase.

Disciplined code review by people very familiar with the codebase is vital.

My personal approach is to create a unit to contain the classes for the "thing" i am working with (e.g. for a 3D world editor, i create a unit that was a TWorld inside, perhaps with TEntity and other classes). Then create another unit for the global stuff (lately i've taken a liking to use a TDataModule which can be edited visually even though it is a non-visual thing - it allows me to place non-visual components in an IDE surface which helps assign event handlers and properties from the editor without writing code for that). Then from the GUI side i just make calls to the global unit/datamodule and/or to methods in the classes i work with.

Of course it all depends on what i'm making, for simple stuff i just throw everything in the form code directly. For more complex stuff i use the method above.

Here is an image showing an example of the approach:

http://i.imgur.com/cm4VTHn.png

The "GlobalState" window is an IDE window that represents a TDataModule (the name sucks and probably is for Delphi compatibility, it doesn't have anything to do with "Data" and because of that i ignored it for years) that contains the "SimpleViewportRenderer1" and "ViewportManager1" non-visual components - instances of the TSimpleViewportRenderer and TViewportManager component classes. This is in its own unit and can be accessed by other units, essentially providing global state (note that a data module is really a class - much like forms - but you can have a global variable with a single instance of it - again like forms). The neat thing with this approach is that it can also be seen by the IDE: the Viewport1, Viewport2, Viewport3 and Viewport4 components in the Form1 form have a property that accepts an optional TViewportRenderer component. This is presented as a combobox in the Object Inspector window and when you pull it down, one of the options is "GlobalState.SimpleViewportRenderer1" - so you can wire together components 100% visually.

Now someone just needs to clone C++ Builder and we'll be all set. Power of C++ with the simplicity of Delphi.

QT Creator is really nice.

QT is really expensive for commercial use though. And it's not as easy as Builder was. Builder basically gave you Delphi capability but in C++. You could focus 100% on the problem you're solving rather than on the UI -- true component based RAD. Drop a few components, wire them together, then add your code to do what they can't do.

No other RAD claiming IDE has the same RAD capabilities as Lazarus or Delphi (or C++ builder), including QT Creator. Live database connection and manipulation while designing your form and data module? Nah, it doesn't even know what a data module is.

We've updated the description from “Proving That Pascal Is Alive and Kicking Ass”. Submitters: the guidelines ask that you please don't editorialize titles.

That headline made people read... and your current title is not fully accurate. It is a Delphi inspired Pascal for sure, but not fully compatible, more like a free alternative.

Exactly. Your title was clickbait and dishonest.

We don't accept that here.

Reply on news.ycombinator.com