- 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?

> 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.

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

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).

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.

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.

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.

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.

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.

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?

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.

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.

what ? no.

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

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

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.

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 ;-)

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.

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

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.

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

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.

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

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

https://eul.im

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

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

I'm checking out Lazarus currently.

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

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

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

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.

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

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

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

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

[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)

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 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.

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.

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.

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.

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.

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. :- )

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.

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

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

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.

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

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;

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.

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

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

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...

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...

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).

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".

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

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.

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!)

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...

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.

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

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.

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

http://tvision.sourceforge.net/

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.

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.

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.

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.

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.

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.

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/

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.

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

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

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

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! =)

what do you call built-in ?

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

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....

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.

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.

We don't accept that here.