Please don't say that "languages are tools". While this is technically right, our thoughts are so dependent on programming languages that they can't be considered "mere" tools. Considering they are make us wrap languages around their implementations, rather than around their users.
I can understand your point, but I came to the conclusion (after 20+ languages) that thinking in just one language can be quite harmful to find a good solution for a problem.
Actually PG puts it really nicely [1]:
"The right way to solve that problem, I think, is to separate the meaning of a program from the implementation details."
"What program would one like to write? Whatever is least work. Except not quite: whatever would be least work if your ideas about programming weren't already influenced by the languages you're currently used to. Such influence can be so pervasive that it takes a great effort to overcome it. You'd think it would be obvious to creatures as lazy as us how to express a program with the least effort. In fact, our ideas about what's possible tend to be so limited by whatever language we think in that easier formulations of programs seem very surprising. They're something you have to discover, not something you naturally sink into."
Sure. But the gist of the rant is that he keeps doing the same repetitive, mundane tasks over and over again, merely to shuffle data from one part of the system to another and convert between representations on the way.
Like when you have a database, a server application and an AJAX web page, you may have four to five different representations of the same data (DB table, server language object, JSON, Javascript object and finally HTML) and need a whole bunch of code just to move data from A to B and convert between representations.
It's not just a language problem. It's just as much a problem of impedance mismatch between different systems, protocols and data formats. Various frameworks attempt to reduce the tediousness, but tend to come with issues of their own.
PG has something on this too:
"Of course the ultimate in brevity is to have the program already written for you, and merely to call it. And this brings us to what I think will be an increasingly important feature of programming languages: library functions."
"I think a lot of the advances that happen in programming languages in the next fifty years will have to do with library functions. I think future programming languages will have libraries that are as carefully designed as the core language."
Whether the common case is made simple by the language, libraries, frameworks or standardization (we may need all of them) ultimately does not matter much to the developer, only that you can handle conceptually trivial everyday tasks with the minimum of fuss.
We have a long way to go before this becomes a reality.
You are absolutely right. Alas, this is mostly applicable when you still have the choice of the languages you will use or build to solve your problem.
When we have settled for one language, though, no matter what we do, it greatly influences our thinking. For instance, I know and love Ocaml and Haskell, yet when I do C++, I have to think in C++ to a great extent. If I think more abstractly (declarative description of my problem, proper separation of concerns, algebraic properties…), I can guarantee the C++ translation will be utterly unreadable, because the mismatch is too great.
Yes. I just think programming languages, as mental tools, have much more influence on our thinking than physical tools. It's easy to observe: I have colleagues who don't know currying and lambdas, others who don't find them useful, and others who plainly don't get it. Programmers. I doubt such blindness applies to physical tools. But that may be because I'm not proficient in manual works.
That said, even if I am wrong, "languages are just tools" is still harmful. This phrase is often followed by statements like "the choice of languages don't matter that much", or "don't whine about your language". These are valid to the extent you have to take into account existing code (read: past mistakes), and team expertise (read: ignorance). However, they tend to overstate these issues. For any big enough project, the technical merits of a language trumps anything else.
