raganwald
(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Sunday, October 07, 2007
  A new way to use the web to compare programming languages


I won’t pretend this means anything too significant, but consider this possible experiment: You know how people do quasi-statistical studies by counting web pages with words in them? For example, counting how many blog posts mention the word “Ruby” and seeing if it’s going up or down?

So here’s my simple experiment. First, start with two programming languages. For example—you thought I was going to say Ruby and Java, didn’t you?—Python and Lisp.





How do the experts solve difficult problems in software development? In Beautiful Code, leading computer scientists offer case studies that reveal how they found unusual, carefully designed solutions to high-profile projects. You will be able to look over the shoulder of major coding and design experts to see problems through their eyes.

Using some sort of semantic search algorithm, or perhaps by employing thousands of people to search by hand, or even just relying on our infinitely reliable “gut instincts” to make an estimate, let’s find all of the What I learned from Python that makes me a better programmer when I use Lisp posts, (and of course all the What I Learned from Lisp… posts as well). If there are a lot more Python -> Lisp posts than Lisp -> Python posts, what does that tell us?

I think if a lot of people write that Python teaches them stuff that makes them better Lisp programmers, it tells us that in some sense, Python is greater than Lisp. It might be the language. It might be the culture. It might be the benevolent dictator. And if the reverse were to be true, that more people write about how learning Lisp makes them better Python programmers… Doesn’t that tell us something about why Lisp is greater than Python in some deep sense?

I think this hypothetical experiment would tell us something about the value of a language for making you a better programmer. I consider that a very important characteristic of a programming language. Popularity comes and goes. Jobs using a particular language come and go. But being a better programmer is forever.

Okay, I know you’re dying to apply this to whatever language flame war is raging at the moment. Fine. The very next time someone complains that language X sucks compared to Language Y… Fire up your blog search engine and see which language has the most to teach you about being a better programmer.
 

Comments on “A new way to use the web to compare programming languages:
If there are more posts saying that language X helped them be a better programmer in language Y, then it can be interpreted two ways:
1. Language X is better than Language Y
2. Language Y is used more than Language X - I cannot be a better programmer in a language I use rarely and learnt for my college project or something like that.
 
Maybe all it means is that language X is older than language Y. It's been around for longer and has had more opportunities to teach people interesting tricks than the new kid on the block.

Yeah, I know. That's a crazy notion. Suggesting that taking a historical perspective on software development might have any value...
 
It's an interesting thought experiment, but I've always subscribed to the idea that even the worst experiences can teach you something. Assembly taught me a lot about C, but it's hard to decide that Assembly is "greater" than C.

Moreover, I think the fact that one is taking ideas from language A and applying them to language B inherently means (at least in some temporal sense) that one has "chosen" language B.

The only thing I can figure out for certain is that knowing more languages is better than knowing fewer.
 
Not terribly reliable. Maybe the person wasn't ready for the concepts introduced in one language over the other. I could just as easily write a post called "What I learned from Lisp the second time I learned from Lisp."

A more interesting question is "What concepts should we really be learning?" That's an interesting discussion that I'm sure has plenty of heat and light.
 
I've been thinking about a "What I learned from C++ that made me a better Python programming" post. Until I started learning C++ in school I never really had to think about how things like strings or lists, actually work "under the hood". Knowing, for instance, that Python's lists are implemented as arrays of pointers tells me a lot of things about their performance characteristics and what I should and should not do with them to get decent performance.

Anyways, my point is that your comparison conflates languages with new concepts they may introduce. If I go from working with Python's Unicode implementation to practically needing to implement my own in Haskell, is it really valid to say that Haskell taught me things about Unicode and byte-encoding in general that Python didn't? I don't think so, especially since if I did a good enough job rolling my own Unicode library no one else on the "Python->Haskell while using unicode" track would learn the same things I did.
 
All of the comment saying, "no, no, this is not valid because for any two languages X and Y, someone could write X -> Y and Y -> X."

Well, of course. But note that I specifically accept that there might be both Python -> Haskell articles and Haskell -> Python articles.

The interesting thing would be if there were 10x as many Haskell -> Python articles as Python -> Haskell articles.
That's all.
 
If there are signifigantly more "X makes me a better Y programmer" than there are "Y makes me a better X programmer", it might be because X is an intrinsically better language than Y- or it might simply mean that Y is the more popular language.

To see how this works, let's compare two languages. X has a million people programming in it, and Y has a thousand, but other than that the two languages are basically equivelent. 10% of both language users learn the other language, and of those, 10% write a blog post aboujt how learning the other language made them a better programmer.

Note that the number of people who know a language is generally much larger than the number of people using the language on a regular basis. So there are 100,000 people who (kinda, sorta) know language Y (at least well enough to write blog posts about it)- but still use language X for their day to day jobs.

Also note that in terms of percentages, neither language is noticeable better than the other- if they had equal numbers of people using them, they'd have equal influence.

But since there are a million people using X, there are 100,000 of which know Y, and 10,000 of which write a blog post about how knowing Y made them a better programmer in X. On the other hand, of the 1,000 programmers in Y, 100 also know X (at least well enough to blog about it) but still use Y as their main progamming language, and only 10 who write a blog post about how knowing X made them a better Y programmer.

So you have 10,000 blog posts about how knowing Y makes you a better X programmer, but only 10 posts that knowing X makes you a better Y programmer. But this is simply a reflection of the popularity of the languages, not on any sort of real worth.
 
Bhurt:

So you have 10,000 blog posts about how knowing Y makes you a better X programmer, but only 10 posts that knowing X makes you a better Y programmer. But this is simply a reflection of the popularity of the languages, not on any sort of real worth.

It's fun to work these kinds of conjectures out. And in some cases, there's real value in considering the implications of even the most outlandish conjecture. For a famous example, Einstein asked himself, "What if acceleration and gravity were really the same thing?"

However, you can also come up with conjectures like "What if the world were created by a Flying Spaghetti Monster?"

At some point you have to look at the actual evidence and ask yourself, "What theory fits the evidence," not "what theory might be true if we add a bunch of additional hypotheses?"

So back to the popularity thing. Do you see a lot of articles explaining What I learned from BASIC that made me a better Ruby programmer?

I accept that someone might write one such article. But I don't see a preponderance of such articles. Or at least, I don't think there were a lot of them before I raised this argument.

So... Your suggestion, although interesting, simply does not fit the evidence I see.
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /