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.
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."
http://www.paulgraham.com/hundred.html http://www.paulgraham.com/avg.html http://stackoverflow.com/questions/1003940/learn-a-new-langu...