Before I go on with this post, I need to lay my preferences down on the proverbial table. I don't loathe Java, but I definitely lean towards more dynamically typed languages for my own projects. I see Java as a corporate language that really has very little application in open source (which is where I spend most of my time). I'm not going to say anything like "Java sucks" but I will say "I don't much care for Java."

I've been doing a lot of JSP/Servlet work recently. It's more for research than for production use. As someone who's done GOBS of web development, I didn't think it'd be too difficult. Writing the code, getting the syntax under my belt, all these things were rather simple. I've just grown use to the idioms used in web development as a whole, and so that wasn't too difficult (Eclipse made it easier as well, once I found a good JSP plugin).

I think the biggest problem to learning a language is running the code itself. My 12-year-old brother was up and running with python pretty quickly, having Ubuntu's Synaptic installer take care of installation, and then using the python interpreter. C, C++ and Java are a little more complicated. They require knowledge of rather complicated tools, provided you're doing anything more than "Hello World!" There are compilers, linkers, etc. Shoot, in all fairness, even writing your own python modules requires knowledge of how import works.

So I'm writing my Java web app, and I'm getting Tomcat all set up to work. Then I realize that there's more to deploying this app then I originally thought. Now I've got to write an ant build file to automate builds (because compiling all these classes and moving them all to the appropriate directories just isn't practical). After that, I've got to deploy it to the Tomcat server. The barrier to entry is just too high.

When I first started playing with Django, the one thing that really grabbed me was the development server that ships with Django. No mod_python/mod_wsgi/mod_fcgi/whatever to mess with just to see if I wanted to invest more time into the tool. When I started with jQuery and ExtJS, I had the javascript terminal in Firebug to play around with the API and find its strengths and weaknesses.

I'm not saying that a language should necessarily be "so easy a caveman could do it," but I do think that there needs to be a low barrier to entry. If it gets complicated later on, thats fine. Shoot, make some really simple, easy to follow tutorials on how to use the tools. Make explanations on the really simple things, like how library paths are structured, etc. Create tools that don't require 200 different command line flags to compile anything more complicated then your standard "Hello World!"

I've been working in a Java environment recently. I've found that no matter how much Java I think I knew in school, it must not have stuck with me. I'm having to relearn data structures in Java, and now that I know a thing or two, I've come to realize that Java's data structures are hugely verbose and rather difficult to work with sometimes. Of course, this is because I've been spoiled recently working in more "fun" languages, like my python...

Consider the following situation. I had two maps that needed to be compared. If you're not a Java guy, think key->value structure. Anyway, I solved the problem by creating a Set (think array) or all the keys that were different between the two, and then showing the results. Here's the java result:

    Set<String> changes = null;
        Iterator it = map1.keySet().iterator();
        while(it.hasNext()) {
                String key = (String)it.next();
                if(map2.containsKey(key)) {
                        if(!map1.get(key).equals(map2.get(key))) {
                                changes.add(key);
                        }
                } else {
                        changes.add(key);
                }
        }                

In python, I just do this:

changes = []
for key in dict1.keys():
    if key in dict2:
        if dict1[key] != dict2[key]:
            changes.append(key)
    else:
        changes.append(key)

Now, I may be nit-picking, but you tell me which one is more clear and concise. Sometimes, being verbose isn't such a good thing after all... (I'm thinking of a specific person who talks way too much)

A very good colleague and friend of mine were discussing development today. Many of my geek friends are sysadmins, and, while that entails some programming, the conversations are usually heavily weighted in other matters, so this discussion was very refreshing for me.

My friend has most of his experience in Java, and much of my Java experience has been from school, so I asked him a question that no one has been able to answer for me: "Why is it better to have something implement an interface in java rather than just inherit from a base class?" Much of his response is stuff that I had heard already, e.g. multiple interfaces can be inherited (which I don't care for, because I think there's better solutions than multiple inheritance), allowing inheritance from a abstract class and then implementing an interface. All of that was nice, but then he said something that I knew, but hadn't really let sink in. We write code for other developers, not for the machine. The compiler makes sure that your code is readable by machine. If that's what your problem is, fire your compiler, not the developer.

My friend then went on to talk about the concept of Design by Contract, which he originally introduced to me months ago (and I have since elaborated on the concept in my personal time). It was then that he used a word that I hadn't considered using before: culture. He said developers need to get into the habit of developing a culture of programming.

Having lived outside of my native country, and having experienced many different cultures, I can definitely appreciate different cultures and ideas. A perfect example: On Sunday, I like to watch the Denver Broncos play American football. A friend of mine who lives in London prefers the Manchester United. When I lived in the Carribean, everyone watching cricket, and I mean everyone. I love soccer and cricket more than I like American football, but it's a different culture. We Americans are very business oriented, quick and to-the-point, while many other cultures are far more "people oriented," and enjoy knowing about a person long before they sit down to work with them.

What does culture have to do with programming? Simple. My culture is no better or worse than any other culture, but it's something I'm used to. Is it perfect? No. Is it universal? Nope. Does it work in this situation? Yup. It's the same with programming. Having worked as an independent contractor, I've had to learn to integrate into many different development teams. This means that I learn the culture of the team. One PHP team can be much different than another, with different practices, different methodologies, and different implementation ideas. Sometimes, there are better ideas than others, but when you start a project in one culture, it's sometimes easiest for developers to stay with that culture, even if another would have better results in X area or Y implementation. It makes the code easier to read, because that "culture" has been developed.

What are some of the ideas you have used in past development cultures that you find helpful? Is it a mishmash of various Agile practices? Was it a consensus of the team to develop a "best practices" guide, and published in a document or on a wiki? What works for you, and what doesn't?

Since there was a Google (and before it was more than a search engine), I've wanted to be employed there. Alas, I certainly am not the best of the best, and probably would settle for someone to call me a mediocre developer (for now). I'm always so fascinated at some of the things Google does, so when Google released their Android SDK yesterday, I jumped at the chance to install it and play around.

First thing I took noticed is the Java. I'm not really a Java guy, and haven't touched it much since I was in school. However, for some reason, this time around, it felt better. Maybe it's because of my deeper understanding of object oriented programming now, or my love for python, but it was actually quite fun to be writing Java code. It required I install eclipse, which, from apt, was 100+ MB of packages, but it looked easier to do with Eclipse than without Eclipse.

I went through their documentation, installing the SDK and Eclipse plugin, and immediately went to the "Hello Android" application. I learn better by diving in and asking my own questions rather than looking at tons of sample code. This whole time, I found some features in Eclipse that I actually liked as well. While the code was simple, it was enough to make me hungry for more.

The best part of this whole process was compiling. Using the Eclipse Android plugin was a breeze (read: EASY BUILD MANAGEMENT!) After compiling the app and running it, I got a pretty little window pop up with a software phone, complete with pushable buttons. The phone's buttons resemble my Samsung Blackjack, but something tells me an Android-based phone will be so much more fun.

I ran into a little snag, however. The emulated phone wasn't running my app. It was just defaulting to the standard Android interface. This was frustrating. It seemed that no matter how I wrote the code, it just wouldn't run what I wrote. A quick hop over to the Android Google Group got me pointed in the right direction. The Android Debugger seemed to be getting in the way. I killed the process and ran my application again. Voila! I got the image you now see above you!

Having dabbled in J2ME, I must say that this is quite a step up for the mobile world. In fact, it's so easy that I'll probably start churning out little apps before the week is out! Great job you Googlees!

Edit: After digging down through documentation and dabbling some more in Android, I've discovered a few things of interest. First, the virtual machine running Android is not J2ME at all, but Google's Dalvik Virtual Machine. There is an entire media library set that supports H.264, AAC, and mpeg-4. That's actually a pretty wide range of media types. The last thing I was rather excited about is the data storage library, which is SQLite. It's constructed in a manner that allows all applications to interface with the SQLite database. My one fear is that the filesystem will turn out like the filesystem on the old Palm OS, where the entire thing was a database. It was kinda ugly...

29 Nov UPDATE An article was posted on LinuxInsider.com detailing the reasons why Android will change the market. I felt that when I started with Android, I still feel that now. Even if it fails miserably, Google's money went into making other businesses sit up and take notice of a platform that eases development.