This post originated from an RSS feed registered with Java Buzz
by Brian McCallister.
Original Post: Babel-17
Feed Title: Waste of Time
Feed URL: http://kasparov.skife.org/blog/index.rss
Feed Description: A simple waste of time and weblog experiment
I wish I could remember the question Matz was asked, at RubyConf,
which lead to him answering Babel-17. I believe it was
something along the lines of "What are languages worth learning?" or
"what are good things to read about language design?" Maybe it was
just "Could you suggest some good airplane reading?"
Anyway, at his suggestion I read Delancey's novella. It is quite
worth reading. Aside from any literary merit, it presents Chomsky's
idea, most widely popularized (as far as I know) by 1984's
NewSpeak, that what you are capable of thinking is determined by
your language, in a novel and worthwhile way.
Because of the context in which I read it, I immediately started
thinking about about how the programming languages we use influence
how we think. People talk about "thinking in Lisp" or "thinking in
Java" not infrequently. Languages do change how you think about
solving problems by making it easier, more natural, more difficult,
clearer, or more succinct to express some ideas rather than
others. I think this represents the real measure of whether one
language is better than another language.
The reason for my believing that the natural means of expressing
something in a language determines if it is better, or worse, than
another language, is that some ways of thinking simply are more
effective. The difficult to argue against (except in Kansas) example
of this would be that solving problems via the scientific method
works better than solving them via the million monkeys
approach. Both are valid ways of addressing a problem, one almost
always works better.
In most domains there is semantic model for the domain which maps to
it better than alternate models, and a language can make it easier,
or harder, to work within a given domain. Low level programming (the
realm of talking to the hardware) is very difficult to conceptualize
via anything but imperative programming, for instance. The fact of
the matter is that you are changing values in registers and using
the values there to determine future actions. This is the nature of
imperitive programming. Good fit, go figure. At the same time, when
modeling mathematical systems you think in terms of pure functions,
and the idea of being able to change state is absurd.
I selected the previous examples because they appear, to me, to be
self-evident and thus good illustrations of the point. In other
realms it becomes much less clear where one mode of thought trumps
another. These examples also illustrate that a given system of
thought may not be universally better (though finding a place where
million monkeys trumps the scientific method might be tough; if I had to, I'd
probably start looking in Topeka).
For me, the mode of thought in ruby (or smalltalk, or slate, or io)
simply works better than the dominant mode of thought in python (or
java, or C++, or awk). Is it universal? I don't know. I have found,
over the last three or four years (since I started using scheme and
ruby) that I write ruby code in Java quite frequently. I have found
that the "really good" code in C, Java, and even Bash, tends to look
like scheme, which is generally most easily expressed (to my eyes
and fingers) using ruby syntax.
Not sure if I have any strong conclusions, just fuel for thought.