Flame Wars

Microsoft vs. Apple. Windows vs. Linux. Emacs vs. vi.

The Web is filled with flame wars. Or to put it a bit less politically correct, religious wars. However, this isn't new, nor is it limited to the net. When Einstein published his papers on the theory of relativity he spent a great deal of time describing observers and inertial reference systems. This is just a formal way of talking about how everything we observe depends on our location and motion.

Reference systems go back much further than Einstein and Physics. In Psychology Maslow talked about the hierarchy of human needs. Shelter, food, community. We all need these things to survive and thrive. The more complex a society, the more we rely on interactions with other people. These interactions are made easier with reference systems. For instance, commerce is easier if we speak the same language. People, for right or wrong, tend to trust other people who come from the same background as they do.

We form beliefs, based on what we are taught by our community, and based on our own observations. Those observations, however, cannot be made in a vacuum and our upbringing and social reference frames will bias our view of the world. There isn't anything we can do about it.

None the less, we end up bumping into ideas and beliefs that are different from our own. Copernicus tells us the earth revolves around the Sun. Albert Einstein discovers that the speed of light is a limiting factor in our universe. Linus Torvalds tells us that good operating systems don't have to come from major corporations.

The issue comes in when people are faced with new information. We do not, as a rule, accept information that is different from our personal understanding. There really isn't anything wrong with this. In fact natural resistance to new ideas has a valuable purpose. Like it or not, we are faced with lots of new ideas and concepts every day. Our social filtering system keeps us from accepting every idea that comes our way. Otherwise we could be victims of various scam artists and just plain false information.

The scientific community has tended to be the keepers of the gates when it comes to new ideas. The first airplane invented by the Wright Brothers was scoffed at by many contemporary scientists. As sad as that might seem, it meant that the brothers had to do extra diligence to convince the world that this really was a new and safe way to travel. Another example would be the introduction of new drugs to fight disease. To simply allow every new drug to be released in the wild before adequate testing is performed would have tragic consequences.

In recent years we have come to think that people who resist change are backwards. They are closed minded and stupid. This is competely wrong. People resist change as a natural defense against harm to themselves and to their community. If there is one thing we have learned over the past century, it is that sudden change can cause more harm than good. People who aren't ready for change, can react harshly to protect themselves. As harmful as the reactions can sometimes be, we should also see them as a positive aspect of a healthy society.

Flame wars come about because we have trouble discussing, in a more civilized manner, things that mean a great deal to us. Perhaps if we can recognize this human response as being a natural part of our defense mechanisms, we can get past the flames, and figure out how to manage constructive change.

Reading List

I've been doing a lot of reading lately. In fact I usually do a lot of reading and my wife, who is a voracious reader herself, is often puzzled by the amount of non-fictional material I pick up. I've been avoiding technical books for awhile now, it seemed I had just gotten too burned out with being a software engineer and so was avoiding that section of the bookstore. Recently, however, I've finished a major project at work (woo-hoo!) and I've been getting kind of restless. I wanted to spend some time refreshing my skill set, and learning something new in the field.

As a result, I've become very interested in Ruby and Ruby on Rails which seem to be taking the web by storm lately. My desk is now stacked with a number of books on the subject.

Ruby Programming, the Pragmatic Programmer's Guide now in it's Second Edition is the defacto standard on the Ruby Programming language. Ruby has been a bit of an ephiphany for me. The two facets (pun intended this time) of Ruby which make it so powerful in my estimation are the fact that it is a pure objected oriented language, and that the author and contributors have provided a rich set of standard methods which are inherited by all Ruby objects. Making everything in Ruby a first-class object means that you do not run into situations where you have to write reams of code to accomplish a task that should have been part of the language in the first place. That's an issue I am constantly running into with Java.

Take iterators and sorting for instance. Not all collections in Java are comparable by default, and sorting the objects they contain is often left up to the programmer. In Ruby, there are only two collection classes (arrays and hashes), however, they can be applied to any Object and provide a mechanism for sorting and iterating directly.

Ruby's syntax, while appearing to be a mix of Java, Perl and Python, actually is more closely related to Smalltalk. Because Ruby provides a rich set of methods and high level access to many features that programmers use frequently, it is quite possible to write Ruby programs in half the lines of code of Java. I've tested this myself by converting some of my own java applications to Ruby, and the lines of code measurement in Ruby is often as little as one third that of Java. There is good evidence that the length of time to complete a project is directly related to the number of lines of code. So it seems apparent that writing in Ruby could prove to be as much as three times more productive.

Of course, Ruby does have it's limitations. It is an interpreted language, which means it suffers from some performance issues. Code performance, however, is not nearly as expensive as programmer performance, and many companies are finding that getting small to medium applications up and running in Ruby is much faster, and far cheaper than doing so in Java.

Ruby on Rails may even be more interesting from a programmer productivity point of view. That, however, will have to wait for my next blog.

Musings

I've been blogging off and on for awhile now. Perhaps that is best, as I prefer to only post when I have something I feel is interesting to say. However, it has only been recently that I've gotten the itch to post about things I actually do for a living. Namely, software development.

I've been creating software for commercial use for over 20 years now, and I'm still learning new things. In fact, it is only recently that I've taken the time to learn some of the 'newer' programming languages, like PHP, Python and Ruby. That's given me a chance to muse on both the practical and philosophical aspects of creating software applications and tools. When I make the distinction between tools and applications, I'm not doing it lightly. Tool building is a vastly different process from creating applications. That's true of creating a house, a car or a computer program. Tool builders are an odd subclass of the group.

In the past, people who built houses often made their own tools for the job. The reason was simple, they knew what they needed to get the job done, and it was rare that anyone else was making tools to sell to other builders. The same can be said for the early days of software development, although it is still somewhat true. Most developers today don't want or need to know how to build a compiler, or why one compiler is better than another.

I'm not really interested in the debates over languages any longer. The issue for me has long become finding the right tool to get the job done. That's all any of us should be concerned with. Of course, there are some people who still get very attached to a particular tool. I'm planning on addressing that particular issue in the very near future.

What I've really become interested in lately is what I call "classes of problems." You've heard the old saying that if the only tool you have is a hammer, every problem looks like a nail. The same can be said for computers and programming languages. The computer is well designed for solving certain classes of problems. However, it is unclear if the machine we call a "general computing device" is really designed to solve all classes of problems. In fact, it is beginning to appear more and more likely this is not the case. What kinds of problems can we solve with today's computers? What kind of problems are difficult to solve, and what kinds are insoluble?

That last question is the interesting one. Do we have classes of problems that computers cannot solve because the problems cannot be solved, or because the design of the modern computer cannot solve it?

I hope to address that question with my postings. I don't hope to answer the question, however. I'll be satisfied if I can simply stimulate the creative juices enough that we can start to imagine some solutions in the distant future.