Hacker News Reader

Comment by gyulai | Hacker News Reader

I used to love Delphi in the late 90s, and if someone could do a late-90s-Delphi-like experience for programming UI-heavy software today, and do it right, and in a way that properly integrates with the anno 2020 tech landscape, then I would love to use such a thing.

In a bout of late 90s nostalgia, I convinced my then-employer in 2011 to buy a license for the professional version of Delphi for a software project I was doing, and I was just absolutely shocked about how far it had fallen behind the curve. It seemed that attempting to support a modern tech ecosystem while maintaining some semblance of backwards-compatibility was giving it the worst of both worlds. Add to that enterprise bloat.

I don't know what it's like today, but I sincerely hope that someone will get it back on the right track (or has already done so, as I haven't retried since my experience in 2011).

View on HN

> I sincerely hope that someone will get it back on the right track (or has already done so ...

2020 Delphi supports five platforms, has 64-bit compilers everywhere, has modern language features, interoperates with C++ through C++Builder, and more. In the past few years especially, we've* seen both a lot of work on it, and increasing interest in using it.

It's modern, and used more widely than one might realise.

* "We've": This is a personal HN account but I work on Delphi and C++Builder.

Thanks for chiming in! I'll give it another spin, if I get some time.

...although language features, 64bit, and integration with C++ were never really where my quarrels were.

If we take "rapid application development" out of its trademarked context, applying just its common-sense meaning, and applying it to the year 2020, then the modern tech ecosystem that one would want to integrate with is clearly not C++, but rather maybe JavaScript & the browser ecosystem, Python, and low-overhead JVM langauges like Scala or Groovy.

The next thing that immediately jumps out at me is that the form designer is still using pixel-based positioning, instead of layout managers and units of length that we know from html, like em (fontsize-based), or vh/vw (percent of view-height/view-width), etc.

I was trying to research these things more extensively just now, but giving you my name, street address, company, phone number, and then "Error: Field required: Yes, I would like to receive marketing communications" for downloading the COMMUNITY edition? Come on! Enterprise bloat: Check.

Haha. 10 minutes further into my Delphi-in-2020-exploration (60% of which was the time that the installer actually took), this was the sequence of events:

* Hit the installer and switched windows, to let the installer work in the background.

* Installer mysteriously gone.

* Tried to run the programme, and it took some digging to understand that the product seems to be in a half-installed state.

* Re-run the installer. This time, keeping the installer in the foreground. Now it works.

* Started Delphi.

* Dropped a button in the form designer to start playing around.

* Oh gosh. Form designer still using pixel-based layouts.

* Deleted the button.

* Doing some Googling to figure out how to do layout managers, and found an interesting youtube tutorial on something called TGridLayout.

* Dropped a TGridLayout on my form.

* Form Designer now caught in an infinite loop bringing up an Error modal that says "Control TButton($17EE2200) has no parent window. Path: ~TButton($17EE2200)".

Thanks Delphi! See you again, another 10 years from now.

...feels like a relationship with an old friend who you've lost touch with when he became an alcoholic, but every now and again you feel bad for him and think you owe him a meeting.

I’m working on yazz Pilot which is supposed to be a modern take on Delphi or Visual Basic. I will take your comment to heart and make sure we implement proper layouts and positioning for the web

We use Delphi for some of our older applications (everything new is migrating to either C++17 or Go). I remember upgrading the IDE (forget which version, but it was about 3 years ago) and after loading my project, I hit F1 to bring up the help menu. The whole IDE crashed... Between little surprises like that and the insane licensing price, I'm glad we're moving off of it. I don't have any objections to the language itself, but the tooling just isn't where it needs to be.

Sorry to hear it crashed. And no idea re the installer. Just out of interest, did you file a bug report? Because I've been using the grid layout recently and have not seen an error.

> Oh gosh. Form designer still using pixel-based layouts.

If you build a desktop app, you'll get pixel-based layouts, because that's how Windows works. It is fully high DPI enabled and scalable, so it's not accurate really to call the units pixels. Call them design units or similar.

As you noted there are various layout tools, from containers with various flow behaviours, through to anchors and padding.

I really wouldn't call it modern, unless you consider C++ modern.

C++ is modern.

C++14 and later are modern. What people commonly refer to as “C++” also includes C++03, which needs to be put out of its misery.

Well, historic stuff obviously is historic.

> has modern language features

What kind of modern language features has it gained?

One of them would be generics, some languages are still having issues implementing them.

It's just the one particular language, and the reasons were political :)

Do you plan to open source it and adopt e.g. Qt-like business model? e.g. charge for service, not tools (except probably some enterprise chart or reporting components).

Hi there! I’m working on Retool (https://retool.com), which is “Delphi in the cloud”. The goal, as you said, is to make it easier and faster to build “UI-heavy software”. If anybody has any comments or suggestions on how we could market something like this, please let me know! In david@. Thanks!

Not sure exactly where your product lands in a continuum between where Delphi was in the late 90s and where Microsoft Access was in the late 90s with its ability to create forms on top of databases, or maybe Oracle Forms. Delphi was the more heavy-duty option for cases that involved a more substantial investment in coding-up actual logic.

Now when I think "substantial investment" and then look at your website, what comes to mind is "lock-in nightmare". Sorry, not trying to be cruel, just wanting to give you an honest opinion.

I mean: Picture a development team pouring real efforts into development work, then training end-users to use the final product. That represents a real investment. And that investment is then locked into a vendor, where it's unclear what will happen to that investment if the vendor should decide to change the pricing model or go out of business.

I guess the original Delphi did have that problem, but the world was just a different one in the late 90s. You bought your copy of Delphi on a CD with a perpetual license, and an organization that had lock-in to Windows NT software would see it as a perfectly viable path, to keep those Windows NT systems running for the next 20 years to recoup any investment in software. Plus Microsoft was actually pretty good (and continues to be good) at establishing backwards-compatibility.

That applies to any platform though. It being open source doesn't mean it won't be abandoned or become poorly maintained. Look at the massive churn web frameworks have seen.

Cloud tooling definitely has the problem that vendor financial troubles = a sudden "our incredible journey" and poof, your app is gone. That's something client side apps don't have to worry about.

Wasn't this the idea behind WinForms and VS.NET? I even think some of the original Delphi people worked on it.

Reply on news.ycombinator.com