> but it doesn't warrant your dismissal I think

I agree that their start in the late-1980s on IBM's AS/400 - Progress was a nice system to build on-top of. But only for those few years.

The main problem with Progress 4GL - just as with all other 4GL systems - is that they're vertical silos: 4GL vendors wanted devs to stay inside their own proprietary ecosystem and they made little-to-no-attempt at integrating with anything third-party. The fact it took until the late-1990s for Progress to add support to SQL to Progress (and require hours of sysadmin work of editing low-level configuration files just to get their "broker" system working) shows where they saw their money coming from: small-to-medium-sized business customers' business systems locked-in to their 4GL system's OLTP model.

I won't go into the major inherent problems in 4GL vertical silos - the fact they've all completely failed or fallen into irrelevance by now is evidence enough (Progress, Paradox, FoxPro, etc). Businesses now realize that interoperability and data portability are very important, which is why database vendors like Oracle, Postgres, and others saw success in offering only a database product - and aim to be the best database product with the best interoperability.

I have an axe to grind with Progress Inc over this very point: there's still a good number of business customers of Progress systems written decades ago that are looking for a way out. I was asked to build a simple data-connector to slurp data from an on-prem Progress database and that's where I ran into not only technical problems, but primarily licensing problems: Progress Inc (the company) made it very clear to me that the only way I'd be able to write a program to get data out of that on-prem database is by ponying up north of $3,000 USD just for an SDK for my own machine, in addition to extra "per-user" licenses for each on-prem site that would be using my software to liberate/exfiltrate their data (never mind that those on-prem sites already had Progress licenses - but they didn't have the right kind of user license). Compare that to the predominant database vendors around today that are either explicitly open-source or give-away developer-licenses to their Enterprise-SKUs away for free - and put effort into making solid client-libraries for rival platforms. Progress' sheer intransigence and their continued opposition to the past 25+ years of industry trends is just mind-boggling.

(I wryly note that only in the past couple of years or so has Progress started to admit their product isn't as great as... frankly, everyone else. So I see they've changed the company's direction away from their 4GL and onto buying-up component vendors like Telerik - unfortunately for them I feel this is coming too late because now even being a proprietary component-vendor feels outmoded given that modern UI platforms and frameworks are well-serviced by gratis and libre open-source offerings, especially first-party libraries like Google's Material Design and Microsoft's Metro/Modern/Fabric/Fluent/WhateverItsCalledThisYear.

----

Footnote:

You wrote:

> inline data manipulation features that long predated Linq etc

From what I gathered from their OLTP system built-in to their 4GL - it's only superficially similar to Linq. It isn't a true relational-calculus system (like Linq) - nor relational-algebra system (like SQL). Please correct me if I'm wrong - my experience with Progress is limited to versions prior to 11 and I understand they have added some modernizations to their platform - but it's still very long in the tooth.

Progress Inc's problem is that their software isn't very sexy, which means they'll have problems attracting the best and brightest in the industry - after all, if you're a hotshot kid from Stanford who solved the object-relational impedance mismatch problem - why would you want to work for Progress?