| Two things. First, constantly having to write implementations like this introduces a ton of friction as compared with reusing existing implementations. Languages do have an influence on that. Second, languages vary in "expressiveness," determining how much code you have to write in order to make an implementation like this. In one language, copying stdin to stdout fits into a natural idiom which also handles other cases naturally. In another language with less care for ergonomics, every task might be equally un-idiomatic. In other words, a language can offer its own "higher order domain languages" for the core tasks that everyone is doing over and over again as part of their general programming.
Or it can choose not to do that, because what it offers is already Turing complete. But then the ergonomics are bad, and it makes a real difference. It seems wrong that when I am paying for things like long JIT warmups and stop-the-world GC, I am still writing piles of functions with low-level idioms that are no more expressive than C's. If Java ships with a 'copy from one stream to another' primitive then I'd find that a much more compelling argument than that I can treat myself to reimplementing things like stream copying, sorting and basic data structures on a regular basis. It's unbelievably tedious and wasteful to do this, there's just no reason. |
My point was that limited expression means of a language are sometimes compounded by inability of a programmer to make a good use of the expression means already available to them.
I also understand the desire for more a expressive language, I am a programmer after all. One has to keep in mind, however, that the more expressive a language is the harder it is on the reader. Java code is trivial for a reader to follow (if not for the excessive verbosity sometimes covering up the true intent); much of Scala code base, on the other hand, is not that trivial to comprehend due to the high expressiveness of the language.