Languagistical Musings

Languages are fascinating. At first thought, you would think that languages are a tool that you use to express the thoughts in your head. But languages isn't like that. It is actually more like a jello mold. For you see, in your head are these molds which hold and shape the thoughts you think.

It makes it easier to express yourself in a language when the thoughts are already formed for that language.

Lots of philosophers and linguists have marked how people think differently based on the language they speak. Here in America, we are only slightly chauvinistic, for while we have pink isles at the toy stores for girls, we still let them play soccer (if they ask first), and even let them vote and have a paying job (not as much as a man, mind you, but we're trying).

I think this has something to do with the fact that English, as a language, doesn't have lots of genderisms. A table is not male or female. It is … well, an it. Gender neutral.

In many languages, there are two definite articles… one is masculine and one is feminine (In English, the definite article, the, is gender neutral). If you have to express your thoughts through a language of specific gender-ness, you will see the world in those same terms.

Arabic, Hebrew, Italian, etc. are all like that, and consequently, my Italian friend won't let his daughter play soccer, because that is a man's sport, and his baby son can't dance. Alright, that was a feeble attempt at inductive reasoning, but if you are curious about the history of how English dropped our genderisms, see Anne Curzan's book, Gender Shifts in the History of English.

I dare say, this is true of computer languages as well. We geeks tend to think that our programming language is a tool to build software, but it is also a mold for how we think about solving the problems at hand. I find it quite interesting to talk to some people who think there is a big difference between C++, Java and Python. While there are differences, they are so insignificant, because it doesn't help you think differently.

There are plenty of people that think that English is a terrible language. While that is subjective, it is true that English is a stew of languages. A mixture of German and French, but with traces of Greek, Latin, Gaelic and others. But does smooshing languages together to make a new language bad… or good?

Make no doubt about it, it does make it interesting.

We like to think of our languages (and just about anything else) as progressing. You know, we started out with machine languages like C, and progressed into functional languages, but then progressed some more into object-oriented languages. You get the point.

But lately, enough of us are realizing that some problems are easier to solve with functional languages, and have started to migrate some of those features, like closures and continuations. Clearly if Java is so complete, we won't have quite the need for so many language ports to the JVM††A nearly exhaustive list can be found here . I took the following snapshot of a session at the 2008 JavaOne conference, that was showing many of the languages that have been ported to the JVM.

But Martin Odersky came up with the idea of actually fusing functional language features with object-oriented ones. It is called Scala, and it looks quite interesting (see the Wikipedia entry for Scala).

First, it is fully OOP like Ruby, Groovy, Python, etc. But the functional language gunk is completely integrated into it… not just bolted on, like they are with Groovy and Ruby.

Examples? One problem that is very difficult for OOP languages is concurrency. Sure we can put a lock on a object, but it is just hard to get it right, when you think in terms of locks on objects.

What about scaling? Object 1 is running on server X and needs data from Object 2. But Object 2, for scalability reasons is running on server Y. The problem is, the data is in the object. Sure that is a feature at times, but it is also a problem when you need to split up the processing.

On the other hand, Splitting up processing to separate servers for scalable reasons is easy with a functional language, since the data is stored in the process. Let's merge two XML files retrieved from two separate servers. In functional pseudo-code, I'd write:

( merge-xml ( get-rest-data someURL ) ( get-rest-data someOtherURL ) )

Each call to get-rest-data can get farmed off in another thread or other server without having to lock, block or coordinate. Adding closures to OOP languages like Groovy and Ruby has been shown to be very helpful. So why not go all the way?

Tell others about this article:

Comment

Have you used C#? 2.0? 3.0?

2.0 added declarative functional syntax, giving you (almost) all of the features of lambda expressions. 3.0 added new syntax to make the more common uses lambda expressions simple and terse.

One of the features that 3.0 added goes beyond functional and imperative programming, and adds LINQ-- effectively giving you a query language to complement your imperative or functional code.

I haven't used 3.0 yet, so I can not give you good examples, but I think you might imagine how effective it would be to program where you can use imperative elements (Do this to that!), functional elements (Do something to that!), and query elements (Do something to something).