This sounds a lot like the commonly accepted definition of "scripting". It isn't necessarily in line with how so-called "scripting languages" are used, but it's an ideal to aspire to, and you really can't fault people for preferring to do general purpose programming in Perl, Python, or the like when they can get away with it (suggesting that designating them specially as scripting languages is itself a bit silly with definitions like these).
Mainstream technology is the very definition of "good enough". Java strikes me as extraordinarily cumbersome and unsuitable as a glue language, though. If you're programming at such a high level where you're just constructing graphs of library-provided objects and piping data through them, the noise in creating and connecting them will overwhelm the signal. Even if you find it's an acceptable cost, someone else will sell an easier way to the world with a fancy name, and the cycle will continue.
That said, I think the case for libraries is made too strongly these days. They make your software hard to build, add maintenance and versioning headaches, and all too often are necessitated only to abate the gratuitous complexity imposed by external requirements beyond your control -- user interfaces, XML, baroque communication protocols, complex file formats, the colossal clusterfuck of a technology stack presented by modern web browsers, and workarounds for the prevailing buggy and incompatible implementations of all of the above. They're certainly useful or even indispensable for many classes of tasks, but rarely are they pertinent to the core of the task being solved, and I regard them as more of a helpful nuisance.
As an aside, it strikes me as disingenuous to discuss programmer productivity as if it were an isolated topic in a world which, in the name of progress, regularly moves the goalposts without a clear conception of the cost, particularly given how often the proposed solution is to fight the unacknowledged enemy of complexity with more complexity.
Scripting and such
This sounds a lot like the commonly accepted definition of "scripting". It isn't necessarily in line with how so-called "scripting languages" are used, but it's an ideal to aspire to, and you really can't fault people for preferring to do general purpose programming in Perl, Python, or the like when they can get away with it (suggesting that designating them specially as scripting languages is itself a bit silly with definitions like these).
Mainstream technology is the very definition of "good enough". Java strikes me as extraordinarily cumbersome and unsuitable as a glue language, though. If you're programming at such a high level where you're just constructing graphs of library-provided objects and piping data through them, the noise in creating and connecting them will overwhelm the signal. Even if you find it's an acceptable cost, someone else will sell an easier way to the world with a fancy name, and the cycle will continue.
That said, I think the case for libraries is made too strongly these days. They make your software hard to build, add maintenance and versioning headaches, and all too often are necessitated only to abate the gratuitous complexity imposed by external requirements beyond your control -- user interfaces, XML, baroque communication protocols, complex file formats, the colossal clusterfuck of a technology stack presented by modern web browsers, and workarounds for the prevailing buggy and incompatible implementations of all of the above. They're certainly useful or even indispensable for many classes of tasks, but rarely are they pertinent to the core of the task being solved, and I regard them as more of a helpful nuisance.
As an aside, it strikes me as disingenuous to discuss programmer productivity as if it were an isolated topic in a world which, in the name of progress, regularly moves the goalposts without a clear conception of the cost, particularly given how often the proposed solution is to fight the unacknowledged enemy of complexity with more complexity.