4GL were supposed to be even more of that, with more "human-language-like" constructs added to the language to deal with things besides general logic, simple data structures and arithmetic.
The author mentions "4GLs" were all the rage in the early 1990s, but I doubt that that was true outside of the mainframe world. The 4GL movement, as a conscious movement, seems to have always been highly mainframe oriented (the Wikipedia article mentions reducing the amount of punched cards necessary for a program as initial goals). By the 1990s you could categorize many languages as 4GL, but I doubt this term was used with any enthusiasm outside of the mainframe world. It was the opposite of a buzzword.
1992 wasn't too long ago. Linus Torvalds has already released Linux, and Guido van Rossum was already working on Python. Perl was already gaining popularity, and Haskell also saw it first versions released. The forefront of technology was already shifting from expensive workstations to consumer-grade PCs and language designers gave little thought to 4GL concepts, even when they happened to design something that could qualify as a 4GL for personal computers (e.g. dBase, HyperTalk, AppleScript).
I agree that human-like text is a bad idea for most use cases of programming, but I think this is not why the 4GL movement failed, and in fact most 4GLs weren't more "natural language-like" than the 3GL COBOL. I think the main problem was that the 4GL movement has never really defined a new generation or anything useful at all. The previously defined generations of language introduced revolutionary changes: translation from friendlier assembly language to machine code (2GL) and compilation (3GL). The only change we can properly define from the loose definition of 4GL is "put more features that used to be external routines or library directly into the language".
This approach worked out relatively well when the language was domain-specific. This is how we got some of the most successful 4GLs like SQL, R and MATLAB. These languages have syntax that deals directly with data tables, statistics and linear algebra directly into the language and became very useful in their own niche. The concept of a general-purpose 4GL, on the other hand, was always destined to boil down to an overly bloated language.
dBase and its numerous descendants and competitors (FoxPro, Clipper etc) were extremely popular for line-of-business desktop applications in the 90s. And, yes, they are indeed traditionally categorized as 4GLs - and, given how nebulous the definition always has been anyway, I think that "traditionally categorized" is the most practical definition that you can use here.
But, yes, I agree that aside from the generally more verbose and sometimes unwieldy syntax, there wasn't really that much to it in practice. I did work with FoxPro, and the reason why it was popular was not because you had to write things like "ACTIVATE WINDOW", but because it had many things baked directly into the language that nicely covered all the common tasks a pre-SQL data-centric app would need - e.g. a loop that could iterate directly over a table.
That class of software also allowed for very efficient data capture against normalised tables. A recall as early as Paradox for DOS (something I haven't thought of for a while) in about 1990 being really simple tools for creating one-to-many database capture 'forms' (with selection boxes, date drop downs, the lot). The richness of form design and tight coupling to the database meant that the language did not need to be very powerful and could just run as a script on top of a rich database environment. The PC-based successor to mainframe 4GL concepts was late-nineties RAD (Rapid Application Development) of Delphi and VB. MS Access was the Windows successor to those tools and was wildly successful as a way for 'business people' to build apps. It took many years for windows low-level app development or the web to catch up to the richness, but they have never really achieved the same level of non-programmer usability.
Yep, and C# (or VB.NET) + WinForms sort of carried that torch well into the aughts. You can still see traces of that all over classic .NET - stuff like DataSet and stock widgets designed specifically for those kinds of CRUD apps such as BindingNavigator.
It's interesting that we have largely abandoned this approach to software development despite its amazing productivity in that niche. I guess a large part of it is because custom-made software is much less common in general than it used to be.
Gosh it's a long time since I heard 'Clipper' mentioned. I used to do 'PC' apps for Banks in the early 90s. Turbo Pascal and Clipper were popular with us. (We used PL/1 rather than COBOL for batch processing)
Then VB 4.0 started to get popular around 1996 and ruled the roost...
So many technologies... does anyone remember 'SUPRA' from that era! (think it was supposed to be a 4GL language/interface for mainframe databases)
Sigh I work at a company that not long ago added support for applications written to use SUPRA to their portfolio. It's not dead yet, there are companies out there still running it in production and willing to spend money to replace it, while keeping their business logic.
Where I work we still use Software AG's Natural for mainframe programming. It's not really a bad language for what it is (very much focused on database programming). The main limitation is that they never created or provided great mechanisms for something like a standard library, so we do a lot in Python now, and occasionally other languages.
From my perspective, the standard libraries of languages like Python and Java, as well as effective package managers such as pip or npm or cargo, have raised the bar so high that it is difficult for old, specialist languages to compete in most cases. Although the security problems of the package managers give me some pause.
I have to disagree that 4GL languages being aimed at the big iron, mainframe world. After browsing the Wikipedia page, there seems to be some confusion around what a 4GL would actually be... For instance, RPG is lumped into this category despite it functioning at a pretty low level and predating the idea by about 30 years. When I first started working with RPG we had worksheets from IBM that felt reminiscent of punch cards.
In my experience, most 4GL languages were aimed at microcomputers and did reasonably well. Others have mention FoxPro and dBase, 4D and FileMaker also slot nicely into this category. IMHO, they had great success in the back office of small businesses.
I have seen some effort to force SQL into this category, perhaps with the idea that a SQL database with stored procedures technically meets the 4GL definition.
The author mentions "4GLs" were all the rage in the early 1990s, but I doubt that that was true outside of the mainframe world. The 4GL movement, as a conscious movement, seems to have always been highly mainframe oriented (the Wikipedia article mentions reducing the amount of punched cards necessary for a program as initial goals). By the 1990s you could categorize many languages as 4GL, but I doubt this term was used with any enthusiasm outside of the mainframe world. It was the opposite of a buzzword.
1992 wasn't too long ago. Linus Torvalds has already released Linux, and Guido van Rossum was already working on Python. Perl was already gaining popularity, and Haskell also saw it first versions released. The forefront of technology was already shifting from expensive workstations to consumer-grade PCs and language designers gave little thought to 4GL concepts, even when they happened to design something that could qualify as a 4GL for personal computers (e.g. dBase, HyperTalk, AppleScript).
I agree that human-like text is a bad idea for most use cases of programming, but I think this is not why the 4GL movement failed, and in fact most 4GLs weren't more "natural language-like" than the 3GL COBOL. I think the main problem was that the 4GL movement has never really defined a new generation or anything useful at all. The previously defined generations of language introduced revolutionary changes: translation from friendlier assembly language to machine code (2GL) and compilation (3GL). The only change we can properly define from the loose definition of 4GL is "put more features that used to be external routines or library directly into the language".
This approach worked out relatively well when the language was domain-specific. This is how we got some of the most successful 4GLs like SQL, R and MATLAB. These languages have syntax that deals directly with data tables, statistics and linear algebra directly into the language and became very useful in their own niche. The concept of a general-purpose 4GL, on the other hand, was always destined to boil down to an overly bloated language.