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
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
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:
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).