Listening To Reason

random musings about technologies by Andy Norris

06 May 2007

Languages Matter

Giles Bowkett is a pretty smart guy, but in his recent post, "Languages Only Do So Much," things run off the rails a bit (no pun intended, for you Ruby fans).

I'm going to pass over his trainwreck of a religious metaphor pretty quickly, except to point out that it's awfully improbable to count the argument that virtually all cultures have a belief system that obeys highly similar principles as a warrant for believing in atheism, a belief system that stands in stark contrast to all of them. Surely it would be more plausible to count it as justification for some sort of religious unificationism. But like I said, let's set that one aside.

The real problem with this post is the notion that if you develop a personal style, you should write more or less the same code in any language. Should good programmers really write more or less the same code in Haskell, Smalltalk, and C? That seems awfully silly to me. They're good at vastly different things, so if you're going to write the same code in all of these, you might as well pick whichever language supports your idiom the best, and run with it.

I'd like to offer a counterproposal: learning and choosing languages is part of developing a personal style. Now, if you're picking between Python and Ruby -- or Java and C# -- the languages may be close enough that you can develop a style that works for either one and switch freely based on the requirements of a particular project. But some languages are very intentionally different.

There's no particular reason to write a web server using the same idiom you use for shell scripting. In fact, I think it's pretty silly to stick with exactly the same idiom in both places, because you're doing very different things. Depending on what your languages of choice are, it's perfectly natural to choose different languages and idioms for these different tasks.

Some of the different things you might need to do in a programming career include systems programing, shell scripting, web servers, web clients (i.e. JavaScript), desktop clients, application servers, scripting for extensible applications, problems that decompose most cleanly using objects, problems that decompose most cleanly using functional programming, and perhaps problems that decompose most cleanly using procedural programming. Certainly not every programmer will need to do all of these things, but most people will need to do a number of them.

It's unlikely that a single language (and likewise, a single idiom) will be an ideal tool for every problem area you face. In fact, I'll go further: trying to use a single language for everything is almost always a terrible idea. Perl started life as a brilliant scripting language, but now it's limping along as a somewhat broken general-purpose programming language. Java tried to be the One True Programming Language, and developed a framework so large that no one who wants to retain their sanity will try to learn all of it, and there is now vast interest in new JVM languages -- Jython, Groovy, Scala, JRuby -- that will cleanly interoperate with all the legacy Java code but are less painful to use.

So here's what I think: by all means, develop your own personal style. All good programmers will do this. But part of your style should be choosing the best tool for the job. If you write shell scripts, figure out what language and idiom are most effective for what you like to write, and run with it. If you write web applications, use whatever suits your style there, as well. Depending on what languages you choose, these may or may not be the same language. If you like Python or Ruby you may like them for both, whereas if C# is your language of choice for web applications, you will probably pick a different language for shell scripting. Powershell, perhaps. Even if you do use, say, Ruby for both, it is likely that you will use a somewhat different style for shell scripting than you use for Rails applications.

If OCaml is your language of choice, you may well choose it for both object-oriented design and designing functional code. If you prefer Haskell, then either you will need to pick a different language for OO, or simply choose not to use the OO idiom at all. If you write Java, you may want to mix Scala into your code to alow you to use functional programming. Likewise, F# offers similar opportunities for .Net. Some of the other languages for JVM and CLR offer additional choices for occasions where dynamic typing may be more efficient than static typing.

My point overall is that for many -- perhaps most -- programmers, a suite of languages that fit together well for you may be a more effective choice than a single language. And even if you find that a single language works for you, it will pay to learn a variety of appropriate idioms for different tasks. Languages matter, and imposing any one idiom on a variety of them is rarely the ideal.

Labels: ,

11 Comments:

At 6:25 AM, Anonymous Anonymous said...

what i get from reading ur blog is that i need to invest specific tool for specific job: c# for windows env, c for linux/bsd, lisp for ai, js for website, perl for scripting, php for cgi, rails for ria, flash for animation and so on

analogously for airlines would be using different type of airlines for different routes/loads; luckily southwest's brave enough to be different -- it uses only one type of airplane for all routes, short or long

heck, even some smart people don't use agenda, address book softwares etc -- they just dump everything on one single file ... and search when needed

too many tools for many jobs will give you enormous mental load -- as always, simplest thing is always preferrable

 
At 6:47 AM, Blogger Reginald Braithwaite said...

I like your argument about integrating your personal style with the idioms each language affords.

I don't see your thoughts in opposition to Giles' post. They seem correct in a way that adds on to his.

I happen to agree with both of you on the importance of learning to use new languages idiomatically.

Having done so, I do think that the importance of using the new language is less than the importance of understanding the new language.

Honestly, can using Lisp do anything for someone who can't program?

In essence, I am saying someone that knows Lisp idiomatically but writes in Java will do better than someone who writes Java programs in Lisp.

Of course, you are arguing for the importance of writing Lisp programs in Lisp, or Haskell programs in Haskell, or Erlang programs in Erlang. And this is obviously a good idea, and I agree with you.

So when I tell someone about your thoughts, I will say: "Giles blah, blah, and furthermore Andrew ..." instead of "Giles Blah, blah, However Andrew ..."

 
At 7:36 AM, Anonymous Anonymous said...

"I don't see your thoughts in opposition to Giles' post. They seem correct in a way that adds on to his."

I don't think it's so much that this post stands in total opposition to the original post, it's just that the original post is so mentally lazy and poorly researched that it's an easy target for better responses.

 
At 9:19 AM, Blogger Reginald Braithwaite said...

the original post is so mentally lazy and poorly researched that it's an easy target for better responses

The only thing of importance to me is whether there are good ideas to be harvested.

If you have to sift through some kibbles to get to the meat... so be it!

 
At 10:31 AM, Anonymous Anonymous said...

"If you have to sift through some kibbles to get to the meat... so be it!"

What irony--that site you link to seems to enjoy serving kibble!

 
At 11:40 AM, Blogger Reginald Braithwaite said...

This comment has been removed by the author.

 
At 11:42 AM, Blogger Reginald Braithwaite said...

that site you link to seems to enjoy serving kibble!

"That site" is my weblog, and I hope it does: As I noted on one of the few popular posts:

Anybody can say you can't write. Let no one say you don't. --Ken Rand

But let's not get side tracked, the comments on this weblog should stay on the topic of what's written here, not on blogging ineptitude found elsewhere.

If you have further observations on the "kibbility" of my writing, please drop some comments right on my blog. You will find you have plenty of company.

(edit)

 
At 1:31 PM, Anonymous Anonymous said...

"But let's not get side tracked, the comments on this weblog should stay on the topic of what's written here, not on blogging ineptitude found elsewhere."

Then why do you keep linking to your blog in response! The reason for this blog post is that this author found the original post to be kibble and he is trying to add meat.

Thank goodness that some people with more knowledge shed light and logic on those with less!

 
At 1:57 PM, Blogger Giles Bowkett said...

I cannot tell you how nice it is to see that somebody actually thought about what I was saying in that post. The big lesson in my experience there is that comparing religion to a pig wearing lipstick is not the way to jumpstart a healthy, rational debate.

of course in retrospect it's obvious.

anyway:

if you develop a personal style, you should write more or less the same code in any language

That's not really what I'm saying. I'm saying that when Carlos Santana plays guitar, you don't say, hey, what a guitar. You say, hey, Carlos Santana.

But if Carlos Santana picks up a Paul Reed Smith electric guitar hooked up to a Marshall amp, you're going to hear something loud and drenched in feedback. If he picks up an acoustic with nylon strings, you might hear something with an element of flamenco in it. Yet it's still recognizable as Carlos Santana.

If you've ever found yourself over-relying on one particular style of coding in a language that encourages a different style, you know what it's like for a mental habit to determine how you write your code. The thing is, certain mental habits should change from language to language and others should not. For instance, if you take 30 Java programmers and teach them all Haskell, you'll probably see each one of them change their data structures much more than they change their style of writing comments. It's not the best example, but my point is, changing languages will change some elements of your style and leave others unaffected.

Comments and variable names are seemingly trivial meta-habits, but API design is a meta-habit too, and API design is a very important meta-habit.
Haskell and Java encourage very different approaches to API design, yet a good API designer will observe some common principles when designing APIs in either language. When I started looking at the source for Monticello, I knew something was familiar before I knew Avi Bryant had written it. That's what I'm talking about. API design decisions he had made in Seaside and Iowa were also visible in Monticello. It was like when you don't know the song, but you do know the band.

 
At 7:49 PM, Anonymous descargar whatsapp para android said...

Thanks for all your information, Website is very nice and informative content.
----
apply baixar facebook gratis and descargar whatsapp gratis and apply baixar facebook

 
At 2:04 AM, Anonymous juegos de kizi said...

I really enjoyed reading.
-----
play game juegos kizi online and play game jogos do friv

 

Post a Comment

<< Home