Does Your Language Shape How You Think? – NYTimes.com
Does Your Language Shape How You Think? – NYTimes.com.
Good article on a question that is always of interest in programming language circles. The modern take, apparently, is ““Languages differ essentially in what they must convey and not in what they may convey.”
The obvious example would be that in explicitly-typed languages, you always have to convey information on what types your functions expect and return:
int plus(int a1, int a2);
while in an implicitly typed language, you don’t:
def plus(a1, a2)
Another example is that in Ruby, if you want to access an instance variable, you use the ‘@’ symbol: @my_instance_variable, as opposed to languages such as Java and C#, where instance variables are not necessarily distinguishable from local variables. Because that’s often a valuable thing to know, one often finds coding standards: naming instance variables with _foo or mFoo or always referring to them as this.foo or what-have-you.
Presumably, the upshot of this is that you ought to seek a language in which you must convey the things that you think are universally important.
The more interesting thing with Python, I find, is the idea that variable name references in functions are local by default, and if you want to refer to a global, you have to actually ask for it. Makes a lot of sense when you think about the evils of globals.
On the more general point (I’d edit my older comment if I could, but I can’t), there is two things:
* Idioms: every language has a culture around it, grown out of a base of source code, starting, at least initially, with the runtime library itself. Idioms can be pretty or ugly or anywhere in between depending on the language primitives provided. Something like C#’s LINQ wouldn’t work nearly as well if the type inference in the lambdas wasn’t as powerful as it is – the type annotations would obscure the intent of the code, and people would reject it as the author being “too clever by half”. Even though the idiom may be perfectly understandable to those familiar with it, when syntax gets in the way, the visual complexity turns people off. Enhance the compiler to reduce the mere syntactic complexity (and leaving the semantic complexity still there), and lo and behold, the same naysayers praise it.
* Learning by example. This follows naturally from the idioms, and the use of a language. You generally best learn the idioms that you are most often exposed to; if the language makes certain idioms clumsy, you may never learn them, to your own loss as a developer. It often requires experience in other languages and other ways of doing things to grow. And again, even if the language is semantically similar (i.e. not talking about wholesale paradigm shifts here), even syntactically similar but with some tweaks, it can make a big difference in the idioms that make sense. C#’s functional features are very primitive by the standards of “real” functional languages, which can do amazing things with referential transparency, such as inlining passed lambdas (which would be an aliasable function / delegate pointer otherwise) into the body of use, and greatly reducing the otherwise prohibitive performance effects of so much abstraction and semantic (but not necessarily physical, at the bits and bytes level) indirection. But imperative as it is, C# has shown many otherwise sheltered developers different ways of thinking.
So I would say it’s not the language that shapes the way you think, but rather it sets what is considered euphonious, and hence sets the bounds on what users experience if they’re not consciously expanding their vocabulary. But a culture can set itself up and borrow words from other tongues, and grow, without necessitating a wholesale switch.