Hacker News Reader

Comment by ksec | Hacker News Reader

Reading this is a strange roller coaster of emotions. Happy to read about good old times, angry about the turn of event, and sadden about the current state.

At the time I thought Delphi was ( and may be still is ) the Best-in-class and a target to beat for all other RAD and IDE. The future is going to be so much better for Desktop App development. Instead we have descended to Desktop Apps with Electron.

View on HN

Delphi is still wildly popular especially outside of the English speaking software development world. It's a bit strange to see. The English speaking developers outside of the US are likely to be following US industry trends, but Delphi and other languages are quite entrenched in industrial programming and custom ORM designs in South America, Africa, and Eastern Europe.

Something really nice about Delphi is it compiles quickly. Very underrated. Modern Delphi has rough feature parity with Java with anonymous classes and functions, making it quite usable. Unfortunately those feature have not made it into FreePascal dialects yet.

The guy who created Delphi went on to make C#. We might see MS's open source push give us something Delphi like yet.

Indeed, here in Germany there is at least one Delphi conference, and additionally it tends to share some slots in .NET conferences.

Where would you find Delphi jobs in Europe? I'm in australia but still do delphi.

Generally firms that work with industrial automation where speed and efficiency are key elements. In wind turbine manufacturing, for instance, I know a lot of firms still use Delphi.

Oh ok, same here then, I'm working in manufacturing, also in medical systems here, there are a few I know of.

Medical systems here as well, laboratory automation, for example https://www.lab-services.nl

In Eastern Europe Delphi was very popular.

How "far" behind it Freepascal you think?

I tried to get into it a few years back and in terms of language features it felt like things had stagnated for a decade or more.

It's not that far behind but there is going to be a time investment for whoever undertakes it. The parser is very modular but documentation is sparse. It follows the EBNF notation quite closely, but adding these anonymous structures will require adding intermediate formats to track them and pass them to the machine code generator.

It's pretty heavy work, but not insanely complicated. One of the gating issues seems the existing devs didn't seem to care about these features when I was looking to add them. That may be a problem for someone who does not wish to invest lots of time understanding the codebase.

Anders Hejlsberg is a world treasure as far as I'm concerned.

After basically single-handedly creating Torbo Pascal, he was the architect of Delphi, C# and now TypeScript. I don't think that anybody touched the lives of so many programmers quite like he did.

I owe to him, having learned that systems programming doesn't need to be C like unsafe, thanks to having learned my ways into it via TP 3.0 - 6.0, before meeting C.

Having done Spectrum coding before also helped.

Not only that, the state of Web app tooling as well, juggling raw HTML/CSS/JS to fake a desktop like UI.

There are low code tools for Web, but they tend to be only for enterprise pockets.

Not only that but they are mostly a lipstick on the HTML/CSS/JS complexity pig and thus do little to really simplify the job. As the thin veneer peels off one is usually forced to deal with the underlying complexity anyway.

I'm a Delphi guy at heart that mostly sneers at all the web UI degeneracy from the last two decades. I do however recognize some important enhancements brought by the HTML + CSS model: enabling Internationalization, Accessibility and Display independence. I'm not sure how modern GUI frameworks do it (Qt/QML?) but these are necessities for modern first class UIs that require a lot of work to get right.

All of those web features exist since Motif days and layout managers.

Personally, DPI independence and screen reader support is definitely not something I associate with the “Motif days.”

Well, it was there, regardless.

Citation needed? At least in actual motif. Can’t find any information about either thing.

I love this seeing is believing in tech.

DPI independence was already supported, because each X Windows terminal was different beast, hence layout managers and multiple coordinate systems.

"Common Desktop Environment: Internationalization Programmer's Guide"

https://www.cs.auckland.ac.nz/references/unix/digital/COSEPR...

"Developing Applications for the Display PostScript System"

https://www.cs.auckland.ac.nz/references/unix/digital/AQ15WB...

Coordinate handling chapters.

"Common Desktop Environment: Application Builder User's Guide"

Attaching objects chapter for layouts

https://www.cs.auckland.ac.nz/references/unix/digital/APPBLD...

"Common Desktop Environment: Programmer's Overview"

https://www.cs.auckland.ac.nz/references/unix/digital/PROG_O...

"Common Desktop Environment: Style Guide and Certification Checklist"

Access and the Style Guide chapter

https://docs.oracle.com/cd/E19683-01/816-0284/6m6phpvqa/inde...

And here is some of the stuff being done back in the day, https://park.org/Guests/Trace/pavilion/unixshar.htm

DPI independence definitely existed in some forms. (Heck, even GDI theoretically had DPI independence baked in, since I guess everyone was inspired by PostScript et al.) And I never really disputed layout management, since I was aware that some systems were doing that, too. I dispute that most systems from that time period could do what we do today and scale correctly on high resolution displays. I’ve had enough experience setting Xresources to be skeptical. But frankly, I just don’t have enough experience with Motif and CDE to really stake a claim here. So I’ll fold on that one: DPI scaling is certainly not absent.

I was most curious to hear about screen readers, because I wasn’t aware of any accessibility protocols or buses on UNIX-likes prior to ATK. But I’m guessing CDE desktops really don’t have that. Maybe the easiest way to find out would be to just boot up CDE and find out, since I’m pretty sure it’s still maintained…

As much as people like to shit on electron, I rather have an electron app than no app when it comes to cross-platform compatibility and features.

The reason why Electron is so successful is because the other UI frameworks simply don't solve the problems people have as elegantly. Doing "custom" UI elements is super easy with CSS and there are many many developers for that, while doing so with WPF or QT requires far more skill and is a lot more quirky.

People don't shit on electron in general, some tech people do. We know what our computers can do when optimally programmed and there they are wasting cycles on rendering badly built web apps. I believe we should be shitting on badly written apps: we can see how a really well written very complex electron app like vscode behaves: then we install some simple crappy app that is not even in the same universe complexity wise as vscode which someone burns 100x more memory and cpu. That we should shit on imho.

> we can see how a really well written very complex electron app like vscode behaves

yes, very much worse than the average Qt app in my experience in terms of responsivity, load time and general UI performance

Agreed. I always shudder when colleagues recommend it. Last I checked it took up an enormous amount of resources for an editor.

My VSCode takes considerably less RAM than Webstorm on the same project - and yet IMHO VSCode does it better.

I mean, "better than a bloated java app" is not really a compliment is it ? Every time I try to use jetbrains IDE I am just unable to given how slow everything feels, my hands start shaking from the stress in merely a few minutes

Well and what editor can you use that isn't either a bloated Electron app, a bloated Java app, or a bloated C++ app?

Comparison to its next best competitor is the only thing that makes sense IMHO.

No recent C++ IDE I know (Qt Creator, KDevelop mainly) has the kind of endemic UI slowness than the others have (recent VS in C#, Electron stuff, Java stuff).

Load VSCode with the same amount of plugins, and measure all of the out of process executables that make part of the experience and then you will see how much RAM is actually being consumed.

I have like 30 extensions to give it the same level of functionality (or more precisely, the subsection I use), and it takes less than Webstorm.

Counting the external processes RAM usage?

Just measuring code.exe isn't enough.

Obviously native does better but people are not writing native apps and if we have to put up with that, it seems time to hold those packaged web apps to some basic standards. I rather have a QT app any day, but I do not work alone and picking software that my colleagues do not use is a continues fight. I worked in vim (with a bunch of plugins) only until begin of 2020 but working in a team just makes that painful in communication and working with some team members.

So I stopped somewhat shouting at the moon and only shouting at the even worse than bad stuff we use. Like chat clients that take up 3gb after running for a few days.

Be the change you want the world to be.

The only Electron app I use by option is VSCode due to its Rust support, and work stuff I don't have a say on what gets used.

And even so, if there is a Web alternative to the Electron package, it will run on a browser tab, done deal.

But it's also a self-sustaining cycle. Actually developing Applications with GTK is relatively straight-forward. I think UI development but esp. cross platform UI development also suffered a lot from fragmentation with both frameworks and languages. So chances finding good documentation for a chosen combination are low.

(And yes, using WPF or QT is ridiculously difficult despite having full-featured IDEs)

Reply on news.ycombinator.com