Programming language barrier

One of the frequent things that I hear about programmers is that it doesn’t matter which language the person is using and which language you need him to use, because if he is any good he’ll learn and catch up pretty fast.  In other words, if you take a decent Java programmer and push him to write PHP code for you, you’ll only have issues for a few days.  Or weeks, at most.

I understand the reasons for this statement, but I don’t agree with it.  At least not completely.

Firstly, the reasons.  They are rather obvoius, but I’d rather stagte them anyway.  Computer Science is not specific to any programming language.  The concepts and approaches are more or less the same everywhere.  Flow control, data structures, and algorithms are not language specific.  Each language has its own best practices and recommended variations, but a bubble sort in PHP will be very similar to bubble sort in Java.   Then you need some common sense, which is also not laguage bound at all.

Secondly, the disagreement.  I think that the Computer Science theory and common sense aren’t the only things that make up a programmer.  What makes a lot of difference is experience.  Programming languages, in their practical applicatoin, are just collections of software – compilers, linkers, debuggers, libraries, IDEs, etc.  Like any other software, programming language software has bugs, undocumented features, and Days When Things Don’t Just Work.  It’s the experience with the language that teaches the programmer how to handle the issues of each software piece.  And that experience is priceless (almost).

Even if you’d manage to push a Java programmer into writing PHP code, that would a waste of resources.  A Java programmer is a Java programmer, not PHP programmer.  He will, of course, learn PHP nuances with time, but, he’ll probably lose a part of his priceless (almost) bagage.  Sounds a lot like misuse of resources.

Another part of my disagreement is not so much reasoned as emotionalized.  I’ve seen a few C and Java developers switch to Perl and PHP for their new positions.  Not that I was forcing them to or anything, but they did.  And the switch was moslty painful to say the least.  Here are some of the areas that I noticed as being hard to comprehend.

Compiling vs. interpreting. Those people who were used to their compilation process were missing something for the first few days.  Some needed as much as a week to adopt, even though write-save-reload browser was done a few hundred times a day.

Debugging. There are two major camps here.  In the first one are all those people who live in the debugger.  They know all the keyboard shortcuts and they have their highlighting customized.  In another camp are people of the simpler nature, those who use print() and die() for most of their debugging needs.  It seems that most people coming from C and Java prefer the debugger way.  Most of the interpretted languages do have either a standalone debugger or a built in debugging tool, but it seems that the majority of interpretted language crowd use the print() and die() approach.

Sigils. If you don’t know what a sigil is, read this Wikipedia page.  Because you do know what it is.  Many strong type language don’t use any sigils.  Most of the loosely typed languages do.  Furthermore, when both the language from which you are changing and the language to which you are changing use sigils, chances are there will still be a difference.  PHP, for example, uses $ for both scalars and arrays.  In Perl though, you’ll get a $ for scalar, @ for array, and % for hash.  Perl’s sigils are extremely helpful when figuring out someone else’s code. I remember the pain of having just a $ in PHP, when I was learning it.  And I can’t even imagine how confusing it is for people who are used to non-sigilized programming languages.

Types. As already mentioned above, strong typed language programmers can be often confused with the fact that variables can change their type on the fly, and that they don’t even need to be declared before use.  Loosely typed language programmers will often complain about the requirement to define their types.  Three of the most common questions that I’ve heard regarding this matter were:

  • “How do I define an array of elements of a certain type of a certain length?”
  • “Is this line a piece of non-sense or does it really do something:   $sum += 0; ?”
  • “What’s wrong with writing:  int amount; amount = 2.5; ?”

There are, of course, more areas than just those – include pathes, include files, OOP, database abstraction, loops (“What the heck is foreach?”), memory management, libraries, and so on and so forth.

Even the list of the resources for each programming language takes time to build.   Yes, time.  And time is one thing that’s always against us.  Everything else we ca handle.

Bloat is bad for you and your code

Steve Yegge has posted yet another of his excellent (and long) rants.  This time he talks about the size of code and why one should jump out of its skin to keep it minimal.

 Most programmers have successfully compartmentalized their beliefs about code base size. Java programmers are unusually severe offenders but are by no means the only ones. In one compartment, they know big code bases are bad. It only takes grade-school arithmetic to appreciate just how bad they can be. If you have a million lines of code, at 50 lines per “page”, that’s 20,000 pages of code. How long would it take you to read a 20,000-page instruction manual? The effort to simply browse the code base and try to discern its overall structure could take weeks or even months, depending on its density. Significant architectural changes could take months or even years.

As I said, it’s a long piece. But it’s worth every paragraph. Even though some Java programmers might be slightly offended by the article, I’m sure it’s not intentional.

What does Sun think about Google’s Java on Android?

Well, nobody knows for sure yet, but Slashdot (yes, again Slashdot) links to this article which has a few quotes from Sun officials.  Interestingly enough, it’s hard to say if Sun will support the open source platform

Jonathan Schwartz, president and CEO of Sun, wrote a blog post congratulating Google on the day of Android’s launch.

or if it will insist on keeping mobile market defragmented

Sun also shared statements that Rich Green, executive vice president of software at Sun, made during Oracle Open World this week about Android. “We’re reaching out to Google and are anticipating they will be reaching out to us to ensure the software and APIs will be compatible–so deployment on a wide variety of platforms will be possible,” he said.

Green also said that Sun wants to work with Google to prevent creating a fractured mobile development environment.

Java chapter in Android story

Blogosphere keeps providing more and more insights into the Google Android story.  As I mentioned in my previous post, Android platform has a lot to do with Java.  In fact, many people consider the level to which Java is integrated into the platform to be the “big news”, unique and all.  Here is a quote from Simon Brocklehurst’s post titled “Putting The Android SDK In Perspective” (read the whole piece, it’s very good):

Android has integrated the Java platform deeply into the phone. In other words, it’s a native application platform for Android phones. No-one has done this before, and it will allow new types of application to be developed (Google has set aside $10M to give away to developers to stimulate development of such software – I hope young entrepreneurs use this opportunity, some great little companies could be started by following this path). It should be noted that Sun’s forthcoming mobile OS platform, JavaFX Mobile, is based around almost exactly the same concept.

After I read the last sentence, I realized that the story is even deeper than I thought.  Google is jumping into competition with Sun, using Sun’s own Java technology.  How is that possible?  Sun was never known for its generosity.  Did it suddenly change?  And what about Microsoft, who invest heavily into both Java and mobile industry?  How did they let this happen?  And what about all those licenses, alliances, and competition?

Google Blogoscoped has an insightful post titled “How Google Android Routes Around Java Restrictions” which explains a few things.  Here are a few quotes to get you started:

Sun released their “free java” source code under the GPLv2 to both win the free software crowd and capture peripheral innovation and bug fixing from the community. For the java standard edition (aka “the cat is out of the bag”) there is an exception to the GPLv2 that makes it “reciprocal” only for the Java platform code itself but not for the user code running on it (or most people wouldn’t even dare touching it with a pole).
But such exception to the GPLv2 is not there for the mobile edition (aka “where the money is”).
This brilliant move allows Sun to play “free software paladin” on one hand and still enjoy complete control of the licensing and income creation for the Java ME platform on mobile and embedded devices on the other

Dalvik is a virtual machine, just like Java’s or .NET’s.. but it’s Google’s own and they’re making it open source without having to ask permission to anyone

Android uses the syntax of the Java platform (the Java “language”, if you wish, which is enough to make java programmers feel at home and IDEs to support the editing smoothly) and the java SE class library but not the Java bytecode or the Java virtual machine to execute it on the phone (and, note, Android’s implementation of the Java SE class library is, indeed, Apache Harmony’s!)

So, here we are: Apple makes the iPhone, incredibly sweet, slick and game-changing and yet incredibly locked. Google makes Android and not only unlocks development abilities on the mobile phone but also unlocks millions of potential Java mobile programmers from Sun’s grip on it.

This is fascinating stuff.  Even if a bit technical for non-IT audience, still fun to read through…