It sounds like you and Alan Kay are both expecting novel problems to be solved by new programming languages. That is an extremely inefficient way to do it: you need to come up with new compilers, documentation, standard libraries, communities, etc. Instead, programming languages have become general enough that most new problems are being solved within existing languages, instead of by inventing new ones.
I have no idea what a "hyper-advanced fifth-generation programming language" is even supposed to look like.
> I'm occasionally wondering if the whole field might not improve mightily if we stopped focusing so much on languages, and instead focused on providing powerful, easy to use, elegant, well-documented APIs for common (and less common) problems.
But a programming language is nothing but a well-documented API! How would your suggested solution even differ from a programming language?
That's not quite it. Let me explain... The first computer language I used was BASIC. It was excellent for what it was, but clearly it had a limit on how much you could do with it, on account of it missing amenities like named functions, variable scopes, etc. A 'function' was simply a line further down the program that you branched to using GOSUB. And there was only one scope, which was fine since the space available for actually writing programs was a microscopic 23KB anyway. It had for-loops, but GOTO was still very much present as a tool to control program flow.
Moving on from there, I learned Pascal, which was clearly a major step up in terms of what you could achieve. Using the primitives available in Pascal (structured programming, named functions, scopes, etc.), it is possible to write larger programs than you can in BASIC: the higher level of abstraction makes it easier to reason about larger programs.
From there C++ was another step up: the ability to define objects and encapsulate a great deal of implementation detail is another weapon in your toolbox to combat chaos, thus allowing you to write ever more complex programs without losing control over what they are doing.
And then... there was nothing. There appears to be no step beyond object-orientation that lets you create even larger programs with even less effort. There may be languages that are syntactically easier than C++ (although after using it for a quarter century it no longer bothers me), but they just hide minor implementation details, at the cost of lower performance. That's not greater abstraction, it's just greater convenience.
What we were all hoping for was that next step: languages that provided an even higher level of abstraction, allowing you to create even larger programs without losing the ability to reasoned about them. This was what 5GL promised, but which we didn't get because nobody could figure out what they would look like. Apparently we have reached a maximum level of abstraction that we can express with source.
So the progression of computer languages looks somewhat like this: 1GL (plain assembly), 2GL (unstructured languages like BASIC), 3GL (structured languages like Pascal), 4GL (object-oriented languages), 5GL (not, as of yet, invented). Each level represents a clear step up in terms of abstraction, and after four steps we seem to have run out of steam, and are now mostly busy reinventing things we already had with slightly different syntax. To me, at least, that's a disappointment.
My disappointment with available APIs is perhaps simply because I program a lot in C++, which inevitably means having to deal with an anemic standard library (there's not even a standardized socket interface in there), and a wild array of C-libraries. Some of these are very good, with an elegant interface design and excellent documentation, but many are just painfully bad, with virtually no documentation, and apparently every effort made to confuse the hell of out their potential users. Really, some of this could be so, so much better...
Isn't abstraction merely an "indoctrinated" kind of convenience?
Surely you can, with a huge amount of inconvenience, achieve in Pascal what you routinely do in C++, by passing "self" into function calls and manually implementing vtable lookups? :)
(You might have a point with C++ templates but that's just saving yourself the trouble of a bunch of copy and pasta....)
Similarly, the "2GL" to "3GL" transition merely gives you the convenience of not having to maintain a call stack. There's no magic, you just save yourself trouble of writing boilerplate code with pushing and popping pointers and stack variables.
I would argue that the only reason it's considered a "paradigm shift" is merely because you were "indoctrinated" into thinking those advancements were so great that they were "more than" mere convenience. But, at least in retrospect, they are _trivial_ when compared with the advancements made in recent years (eg. Garbage Collection, Rust's safe memory management, import tensorflow, etc.). And while the old school programming language advancements surely boost programmer productivity and accuracy, I don't think it's fair to say they're more important than say the convenience of an "import fancypackage" that does 90% of the work for you.
Perhaps the form of improvement is often not in a new programming language (because perhaps classical languages are "good enough" for most cases), but I know I wouldn't enjoy programming with the tools available 20 years ago.
PS: I suspect your C++ perspective might also have tinted your perspective a bit. For the examples I gave as more recent advancements (i.e. GC, Rust, TF), they aren't (readily) available in C++. Sure you can say you prefer the speed of C++ which is entirely fair, but you might be pleasantly surprised if you looked outside.
Indoctrination: perhaps it is, but I don't think so, since other people make largely the same distinction, as witnessed by a series of articles on wikipedia (https://en.wikipedia.org/wiki/Fifth-generation_programming_l...). Although they have a slightly different definition of 4GL than the one I used.
Ultimately Turing-completeness means there is no difference in what you can achieve with various languages. What matters are other things: the convenience of getting the work done, performance, etc. In my experience Pascal and C++ really do differ significantly, with C++ allowing you to automate a hell of a lot more than Pascal would.
I disagree that GC is a more meaningful step forwards than, say, structured programming - this is something that is now so pervasive that it is no longer recognized for the revolution that it really was. GC is just one method of freeing memory, but it's not the only one; C++'s RAII does the same, and tracks any resource you care for, not just memory. I totally agree on the importing though. Arguably vcpkg has been a game changer in that sense.
Programming 20 years ago wasn't all that bad, really. Figuring something out usually meant reading a book. There were fewer useful libraries around and they were less capable, but on the other hand, they also weren't as ridiculously complex as today's libraries sometimes are.
And I'll readily admit that C++ informs my comments ;-) I mean, I've been writing C++ since 1996 or so, and for most of that, pretty much full time...
What I've observed is that programming languages have significantly caught up with the math behind them. And it's not uncommon for some of the nearly-cutting-edge math to be hundreds of years old, or more. I recently looked into algorithms for finding the GCD of two numbers, and Euclid's algorithm from 300 BC is still basically the best way to do it (with an optimization for our binary representation happening in 1967). As programming languages catch up to the underlying mathematical theory, they're going to start progressing at the pace of math breakthroughs. That kinda sounds like a good thing to me.
I don't see object-oriented languages as the pinnacle. Notably missing from your list are functional languages, which I also don't see as the pinnacle, but rather "beside" OO langs. A 5GL to me is one that incorporates the best of each paradigm. I generally program in C# and TypeScript, and I'm constantly switching between an imperative style, an OO style, and a functional style. C# is almost my ideal language; its type system is just a little too weak. Perhaps it's a 4.5G language. But let's look at what you can do with it:
* Strong OO support
* First-class functions (functions-as-data)
* Strong support for reflection, allowing powerful IoC and types-as-data
* Good generic type support (reified! Yay!)
* Generators with yield
* Async/await flow programming, including "yield async" mixing the two
* Low-level bit manipulation, arrays of structs (certain memory guarantees), unchecked operations when you need them, and other C-style concepts
* LISP-style macro manipulation (code-as-data) using Expressions (under-appreciated IMO)
* No higher-kinded types :(
* LINQ, if you're into it ... but I prefer fluent because it's more extensible and language-idiomatic (although you can write your own limited LINQ-style methods)
Add in higher-kinded types and how could you not call that a 5GL? I honestly don't know what else you could possibly want from a programming language, except maybe Rust's borrow checking (which frankly is a recent breakthrough in computer programming, kinda challenging the premise of this whole thing).
My next big idea is a programming language whose type system is written with the "same sauce" as the language itself. So the output of a "program" could be the type system for another program. You could write your software in "tiers" of progressively more strict/knowledgeable type systems. That's one thing I haven't seen before that sounds neat, but who knows if it's actually useful.
I have no idea what a "hyper-advanced fifth-generation programming language" is even supposed to look like.
> I'm occasionally wondering if the whole field might not improve mightily if we stopped focusing so much on languages, and instead focused on providing powerful, easy to use, elegant, well-documented APIs for common (and less common) problems.
But a programming language is nothing but a well-documented API! How would your suggested solution even differ from a programming language?