Programmer's Religion

I've been thinking a lot about programming languages. It occurred to me that I know quite a lot of them. Though I personally prefer Java, I've also written code in C++, C, Pascal, various assembly languages, HTML (a kind of language), Javascript, XML, SQL, and a variety of others professionally. For amateur projects, I've used PHP, PERL, VB (ick!), C#, and now Python. I even took a shot a LISP once. So, I don't have a lot of religion about what I program in. They all have strengths and weaknesses, good and bad.

So it came as no surprise when a very knowledgeable technologist asserted to me that a good programmer could write code in any language. As expected, I agreed. Being a polyglot programmer myself, it certainly seemed correct. At the time it did. But maybe...

Since then I've come to believe that you can write a program in just about anything but not write code professionally in more than a few. Modern coding requires more than just understanding computer languages. With the exception of a few outliers like LISP and SmallTalk, most computer languages fall into a handful of syntax groups. Java, C++, C#, PHP, and Javascript are so similar that it's hard to imagine any experienced programmer not getting the basics.

But only the basics. The problem lies in what it takes to be a productive programmer. Understanding how to program a computer or write in some language is less than half of what you need to know to do it professionally. Enterprise applications especially are built around entire frameworks and environments.

Take Java. There are several graphics built-in libraries such as AWT and Swing. It has a rich set of general collection objects with the ability to adapt them to any type of object using simple syntax. There are lots of utility, security, reflection, multi-threading, and database connection classes. That's not even getting into Enterprise JavaBeans (the middleware/SOA framework) or servlets which are used for web programming. Keeping up requires books, training, and on-line resources. You have to focus on staying current with changes and new additions.

This is where the difference lies. There is Java the language and Java the development environment. C++ is a language but C++ in the .Net environment is what you write code in. It's very difficult to focus on being expert enough to be a productive in more than one of these complex environment. This is why you see programmers with so much religion around their languages and environments. .Net people can be passionately pro-.Net. Java people can be Java bigots.

It's a natural side effect from all the effort that goes into being expert enough at something to do a good job with it. It's not that one environment is better or worse – all have their strengths and weaknesses. The demands of being productive in any particular environment require that you focus all of your attention on being good at one thing. You can switch languages and environments but it's like switching religion. It can be done but it's a process that will take time, effort, and will.

So, I take back what I've said in the past. A good programmer needs to have religion. Not religion in the sense of unquestioning zealotry. Religion as in a deep devotion to their craft and a singular focus on what they are doing.

I Can't Cotton to On-line Office Apps

I still don't like on-line office applications. It's not that I have anything against on-line applications. Heck, the company I work for (and the line of business that I run) sells that as an option for our customers. I love Xpenser, which helps manage expenses and Stikket which is an on-line sticky note app. It's the office apps I can't cotton to.


To start with, they all feel somewhat lightweight to me. Let me put it another way - most are only about as good as a decent text editor. Even for people who just want to write a letter, on-line office applications offer too little in automation and features. You can enter basic text or numbers and perform some simple editing functions but that's it.


I'm writing this on Google Docs and am not enjoying it a bit. I want margins! I know this is electronic and going to get published to a blog but if I wanted to print this, it would be ugly. It's also very web-centric. If you look at the style menu you see typical internet styles like "Heading 1". That's an HTML programmer's idea of how to write documents not a writer's. There is no way I could write a memo on this, let alone something substantial like an article.


Now, I can already hear the howls from the promoters of these applications. They will say "on-line applications are not meant to do everything a desktop office suite does" and "your expecting too much". All I'm asking for is basic functions. I'm not suggesting that these apps be used to write the great American novel, just simple stuff like the kid's school papers. Wordperfect circa 1985 has more functionality.


There is also the whole problem of it being on-line in the first place. It's great to imagine that you can access your documents from any computer in the world. That assumes you have a network connection. Without that, you can't access your documents from anywhere in the world. So, while the dream of documents everywhere is a great one. It doesn't help if you can't get to them. Once your network connection is down, they may as well be at the bottom of the ocean.


I don't mean to beat on Google Docs alone. All of the on-line office apps are like this. They have no choice. If they add more features then dragging that code across the Internet will eat bandwidth like frogs eating flies in late summer. This is why I think the whole concept is flawed. Applications that encompass lots of back-end processing but few upfront features are great as Software as a Service. Applications that need to have a lot of features on the front end do not.


What makes this especially amusing is that there are free alternatives such as OpenOffice.org. It's not like the only choice is to buy a professional office suite for $500.00 or use the on-line apps. There is a free but full-featured alternative.By the way, I hate having to use the ".org". Someone should fix that situation.


So, for lightweight writing tasks like blogging, the on-line apps are certainly interesting. For most anything else, they are useless. I'll stick to OpenOffice.org.

All You Need is Love!

It's true. All you need is love. So, do we really need another scripting language? Ever since Perl and Javascript showed us that we could crank out code quickly by using a simpler, non-compiled language, scripting languages have proliferated like nuclear weapons in the 1960s. Besides the old languages such as C Shell, AWK, TCL, or SED, and the middle period ones like Javascript, VBScript, Flash Actionscript, and Perl, we nowmust contend with a whole host of new ones.

In the last few years we have seen the emergence of Ruby, Python, and PHP. All have their adherents who defend them with nearly religious fervor. PHP has become one of the most deployed server side scripting languages while Ruby is often used for interfaces that provide rich user experience (in other words Web 2.0) web sites. We can also add to the mix Java Server Pages (JSP), a scripting language for Java Servlets (popular amongst the Tomcat crowd) also for user interfaces. On top of that, Javascript has been extended and integrated into the AJAX model to provide for pretty much the same purpose.

Now, we can add a couple of new languages or environments to the mix. Some have been pushing Groovy, another servlet-oriented language. Despite the obvious Java-oriented scripting language proliferation, Sun has seen fit to launch yet another scripting language, JavaFX. Microsoft has also announced its scripting effort called Silverlight, despite have ASP.Net already.

Why do we need all of these languages? My take on it is that software companies need to have an entry in this space. Most scripting languages have come from the user community, with Javascript being a notable exception. Unlike compiled languages, which typically have high learning curves and need extensive tools, scripting languages are easy to learn and implement. By creating new scripting languages, many of which are similar to proprietary compiled languages, they extend the franchise in the part of the business that makes them money and neutralizing the user scripting languages which don't. This explains Sun and Microsoft's latest announcements.

I also think the open source and hobbyist communites feel compelled to develop new scripting languages because they simply don't like something about existing ones. It usually starts out with the need to have a language that solves a very narrow problem and expands into a general scripting language. Python and Perl comes to mind here.

The result is too many languages that offer few benefits over existing ones. Most are similar to another language but not exactly the same. This leads to a large number of mistakes that actually slow down coding. Anyone who writes both PHP and Javascript will know exactly what I mean. It also makes for a confusing landscape when trying to choose the what languages to use for a project. What I want is a language that can be implemented as compiled code, client side scripting, or server side scripting. It should start with a standard computer language syntac like C++ or Java. That way I only have to learn one language and can use it for everything. I can also start junior programmers on the more stripped down client side scripting version and work them up to the full, middleware enabled, component-oriented version used in my high volume server applications. This is something for Sun to consider since they, more than anyone else, have the capable to deliver this breadth of options based on the same core language, specifically Java. Microsoft might be able to accomplish this if they standardize on C# syntax.

Scripting languages are a very good idea. They allow for rapid, iterative, development, are exceptionally useful for user interface programming in browser-enabled applications, and make it much easier to deploy small applications quickly and with few resources. They also helped recreate programming as a hobby, something that was on the verge of disappearing as professional programming became more complex. We just have too much of a good thing and need to pare it down a bit. That way we can get on with writing code and not learning new computer languages.