Rant: Names Are NOT Identifiers

Names Everywhere

I see this happen often: Someone creates a list of items with a "name" column. The backend team uses the name to fetch and compare these items. The UI team uses the name as a human readable description. Hilarity ensues.

Let me back-up and give an example: Let's say we have a list of states that an order can be in, things like "New", "Being Fullfilled", "Shipped", etc. The backend team, naturally, writes code like "Transition all the orders that are in the state 'New' and over 2 days into the state 'Overdue'". The front-end team creates a list of Orders that clients can view online and places the state name on the screen.

So what happens when it is decided that "New" needs to read "Pending"? If the UI team changes the name in the table to "Pending", all the code written around lookup and comparison to "New" breaks!

Names are Two Concepts in One: Identifiers and Labels

What happened here is that the developers confused the concept of an identifier with a label. The former should never be shown in a UI, but should always be used by developers for look-up, comparison, and whatever else they need. The latter should only ever be used for user display, and never for anything else.

In other words, mixing these into a single column is a layering violation, because you are mixing business logic and user interface display layers together! Making sure you don't breech these layers ensures that you can change the label all willy-nilly at anytime and not break anything.

What About My "id" Column?

As a last note, I often get asked (which pertains mostly to users of ORMs that rely on a numeric id column as a convention) is: why not use the numeric id as an identifier? In a small project this is probably fine. But in large or long running projects, it can get more complex: Sometimes the table's contents aren't predicable enough. FOr example, sometimes you have multiple clients running the same application, but with different (developer defined) entries in their own databases. The numeric IDs just aren't reliable because they are created via a sequence counter (auto-increment, serial, whatever). You are just asking for trouble if your project becomes anything more than a pet one.

Rant: Proper Planning is Pivotal

My brother and I are, on the side, developing some software for our own enjoyment. However we take our development effort seriously, and have spent a good deal of time writing small technology tests and, most importantly, documenting our specification so that we can agree on the path that we are taking.

Our spec is mainly composed of two things:

1. The feature specification, and
2. the architectural plan.

Both of these are important. Even if everyone agrees on the features that should be implemented (and we'll assume that there weren't the normal communication issues involved in doing this without a written spec), everyone's programming/architectural styles can be incredibly different.

Unfortunately, this can lead to a mess later.

The Draw

It is very tempting to ignore this obvious fact, especially when you have small teams of developers working under tight timelines and budgets. Your team will find itself having one-hour meetings to verbally discuss a feature and how it should work, and then the developers will all run off to their caves and start writing code.

Initially this actually works out really well. Everyone is building their separate pieces, plugging along and writing code in the way they write best, which results in quick turnaround.

It is a manager's best dream. Everything is getting done ahead of time and under budget!

The Problem

But what happens when the pieces have to start fitting together?

At some point the pieces that everyone writes have to start fitting together. If everyone is writing to their own architectural drum in their own style, how easy is this integration going to be?

Even worse, how many of your developers are good architects? Did those quick up-front times result from the developer doing whatever was quickest to get their pieces done? What happens when, as anything in real life happens, the spec changes a little? How about when it changes a lot?

And none of this includes what happens when developers have to work on eachother's code. Where is a document to help them figure out what was done, especially since the code is so incredibly different from their own?

It Happens

These aren't all hypothetical questions. I've encountered this problem in the real world. Specs aren't thought out and aren't documented to save time. It's alluring. I've even bought into it. Turn around times are fast and everyone is happy...

...at first.

But after a year on a project, this can start to turn around. You start discovering all the webs of spaghetti code that were weaved to meet deadlines, and the hacks involved when a developer didn't want to spend the time to ask someone else how to integrate with their component, or the bugs that appear because of the bad assumptions that lazy programmers will make.

I've seen all these problems over and over again, and sometimes these problems can bog down development to the point that whole sections of code must be stripped out and re-written to get around it.

The Solution

In programming, the money is where there are hard problems that need to be solved, and hindsight is 20/20. So no matter how much planning you do, you'll never be happy with your solution. There is always something that you should have done.

Which is why architecture is so important. If architected properly, a system is set-up so that when these problems are found, they are easier to solve. One must strive for expandability and refactorability, but without spending time creating interfaces and functionality that are never used.

As I always say, a good software architect dares to dream and plans ahead for the future, but knows where to stop to keep development times and costs down.

For this to succeed, there must be somethind that is in control. Something that is guiding everyone else towards a common goal.

That is the architectural spec.

The Spec

Of course, someone has to create the spec. That should be the job of multiple people. Ideally, there should be an open dialog between the developers that are writing new code, the developers that wrote any code that is being interfaced with, and an architect that can coordinate the input from these developers into the common design goals and styles of the application as a whole.

And this is easy to do with the small teams that are usually lured into ignoring spec writing altogether!

Words of Advice

My advice to you: whether you are two programmers or hundreds of programmers, specification documents, and clear architectural leaders, are important to the overall long-term success of your software.

You may be tempted by The Devil to ignore proper specification in order to achieve the impossible up-front, but like any deal with The Devil, you better be prepared to tackle the ugly consequences that follow.

Rant: Auto-Refresh News Sites

I was reading and article at www.computerweekly.com this morning, who, like many other news sites, seems to think that they need to force a server side refresh on the whole page every five minutes to reload an article so that I can have the latest, greatest, news in some ticker.

In this case the problem was that their server is flaky, and on refresh, it gave me a "Server Too Busy" error! So now instead of getting to read the article (which was apparently in necessity of updating because the content of individual articles changes so frequently), I get to stare at an error message generated by a Microsoft Web Server.

This is just the most infuriating case in a string of annoyances with auto-refreshing news pages.

One thing I consistently find annoying is how Google News has to refresh the news listing on me, while I'm browsing through the article summaries.

Indeed, it always seems to do it when I am about to click on the link to an article I think would be very interesting to read, and it always seems that that article has rolled off the bottom of the list and I have to dig around if I want to read it!

Now the question on my mind is "why"? Why do we need to have our news updated so frequently (or at all)? Did so many important things happen in the course of the ten minutes I was reading the site that I need to have it updated?

And if I'm that addicted to news, what am I going to do for the hours that I'm actually working? Or for that matter, how do I possibly think I could make it through a nights sleep!

Or is it that they think we are so freakin' lazy that we can't hit 'refresh' several hours later to reload the page if we want to be ten extra minutes up to date with the cutting edge news?

Rant: Rails Lacks Accessor Bottlenecks

Being a longtime user of (and zealot for) Ruby, I have a made a name around the office for my unusually strong understanding of its details. Thus my employers decided that, out of our team of developers, I should be the one to write the security sub-layer for our Ruby on Rails based chiropractic applications (as it would require digging into, and understanding the internals of Rails.

Now before I proceed to beat Rails around a littl bit, I don't want you to get me wrong. I love using Ruby on Rails and would easily chooose to do this project (and future projects) in it again, but sometimes I find some of their design decisions to be, well, web-developerish, while we need a more robust enterprise-developerish solution.

A Bottle With Too Many Openings Can't Hold Water

One of the design patterns that I have seen over and over again in Object Oriented APIs is the use of bottle-necking. That is to say, even within your own class, you choose to use a set of accessors to get at instance variables instead of poking at them directly.

The big benefits to this approach are two fold: It allows you to be more agile with changes (as you only have edit the accessors to change behavior), and it allows third part developers to easily augment or override the default behavior of your code.

An simple example of this may be a simple vector class that stores a magnitude and an angle. Now this angle, in all reality, needs to be between 0 and 360 degrees. So if you have two ways to set this data (from rectangular or polar coordinates), you would have to enforce these limits, probably by using a modulus operator. (Which isn't very DRY, now is it?) But what happens when you have to change the behavior? Maybe the angle needs to be stored in radians, maybe the range needs to be changed to -90 to 90, or maybe it needs to be compass oriented instead of right-handed-axis oriented? Or maybe you just want to add a way to set the angle without changing the magnitude?

All of these requires refactoring your code, which requires duplicating and/or altering your code in several locations! But if you were to make a single accessor for getting, and a single accessor for setting the internal value, then all your other code could go through this accessor (including possible intermediate accessors) to enable fast, agile, and DRY code changes!

Playing With Steam Engines

So, now, let's imagine your employer gives you the spec that your enterprise Rails driven software must have a security system where you can restrict read and write ability to different models, on a per attribute basis. This is what I faced over a year ago.

The way I really wanted to solve this was to override the accessors to the basic hash that stores, as key/value pairs, all the data for the table row the objects represents. That way I could add my own code that would allow or deny access at this fundamental level.

Unfortunately this basic and simple idea (based on past experience with other APIs) exploded in my face. You see, the @attributes hash instance variable that ActiveRecord uses to store these key/value pairs is directly poked and prodded by many separate methods throughout the ActiveRecord class. Thus I had to override all of these methods, making them call the same friggin security check method, to decide if they could continue onto their default implementation or if I should restrict access. (I'm only lucky that the runtime generated accessors utilized standard accessors, or else I'd be re-writing the code-generation routines as well.)

Of course, all this work meant that besides sinking a lot of the company's time and money into implementing a task that should have been simple, maintaining our release against newer versions of Rails is more costly because of all the hacks I've had to do to meet the requirements.

Which is why I'm so peeved at their code. If only they had followed good design practices and bottle-necked all calls to @attributes through a read and write accessor method, it would have been easy to implement customized behavior at this point in the program flow, and thus would have made my security requirements a trivial task.

Rant: Marching Forward; Why Should I Upgrade?

With the oncoming release of Mac OS X 10.5 Leopard, I feel compelled to rant about a post I saw on the discussion board for the open-source software AudioSlicer.

On this forum there was a post that seemed like the author was taking out his frustrations on the AudioSlicer developer that software was not backwards compatible with his old version of Mac OS X.

Now, if I picture myself as the average user, ignorant of anything to do with software development, I can see where the guy is coming from. However, as a developer, I find his attitude to be quite maddening, particularly because AudioSlicer one man's solution to a problem he was trying to solve for himself, and was nice enough to share it with anyone who wanted to download it!

Building a Home Of Code

Building software is kind of like building a home. Each operating system gives you a set of tools and building blocks to build your "home", and then you figure out how to stack them with building blocks of your own and glue them all together to make an application for people to enjoy.

In the old days, there were no power tools and, depending on the place and time you lived, you might even have to your own plaster and maybe even cut down your own trees. Thus, most of your time, energy, and money, goes just into building things for construction, much-less building a complex and interesting house.

In modern times, however, you are lucky enough to be given power tools, pre-cut lumber, drywall, and fiberglass insulation, allowing you to spend more time on building the house the way you want it, and less time preparing to build.

Now what happens if someone wants you to build that nice modern home but with old fashioned techniques and materials? You'd have to spend inordinate amounts of time re-inventing technologies such as drywall and fiberglass fabrication, and spend large amount of time overcoming the lack of power tools and even back-hoes!

No contractor would dare to take on this task because it is just not economically feasible for anyone to build a modern house using old-time building techniques.

The same is true for software developers. We are given many building blocks and tools from our operating system manufacturer that smart people have spent months or even years developing and testing, and then we take advantage of their hard work so that we can focus on building better software applications for end users.

Jaguars, Panthers, and Tigers, Oh My!

Most users were very unimpressed by OS X 10.4 Tiger's release, and I can agree with them. From a user's perspective, it was a lackluster release. It was hard for the average person to justify spending $130 to upgrade from their comfortable and productive little OS X 10.3 Panther machines.

But what these people didn't realize was the massive amount of really cool new building blocks Apple gave developers. These new building blocks (called APIs if you want to learn a new word), got developers very excited as it allowed them to make much better software for a lot less time and cost.

As a result, several months after Tiger was released, a flood of cool software came out that could only run on OS X 10.4 Tiger. This, of course, caused all the people who wanted to stick with OS X 10.3 Panther to complain that no one was releasing their cool new offerings for them.

The Amish Can't Have Cell Phones

As much as many people hate it, technology marches forward at a breakneck pace. What was sate-of-the-art in computing four years ago is slow and a useless novelty now. It may be cheaper not to upgrade, but to stay in the past is to be left behind.

If you refuse to buy pre-manufactured building materials and use power tools to build your house, you can't expect the same quality of house for the same costs and built in the same small amount of time.

So why do you expect anything different from software developers?

Misunderstood

Development is a very long, complicated, and expensive process. Most software projects--even while taking advantage of all the tools and building blocks they have available to them--still run significantly overtime and over-budget. So how do you expect developers to find the extra time and money to spend the months (or even years) necessary to re-invent building blocks from scratch, just so that you can live in the past?

Indeed, in reality, many new pieces of software that require new building blocks were only ever made because the new building blocks exist. CoreData and CoreImage allow developers to build database-driven libraries of scanned images, and Cocoa Bindings allow developers to build whole CoreData driven GUIs without touching a hardly any code. Without these nifty new technologies, cool applications like Delicious Library would be such a chore to make that only companies with large development and marketing budgets would be able to build them.

Change Course Into The Wind

The world is always changing, and technology is no different. People are scared of change. But those who do not cope with change get left behind while those that embrace change become successful. As much as it can be a large time, energy, and monetary investment to change, it is worth it to yourself and your family to learn and adapt...

...or don't complain when you get left in the dust.

Rant: Fixing Bugs is Like Solving a Crime

So I got a bug report the other day, from our own staff member no-less, that simply said: "Can not 'submit fixes' in finalize screen."

Now let's think about this for a minute. Fixing bugs is very much like solving a crime. You are presented with a bunch of clues about what went wrong, and now you have to follow those clues down different avenues to piece together what went wrong (which is a very time consuming process to do right). But you have to do this, because you can only fix the bug when you understand why it exists.

So, now, if you were a police detective and someone called with the brief report "I found a dead body", would you be able to catch the murderer? You don't even know where the body was found to be able to start collecting crime scene data with your trained eyes. It would, thus, be an impossible case to solve with just the information provided from your well intentioned, possibly anonymous citizen.

So, then, how does the submitter of such a brief bug report expect me to solve their bug?

The Things You Need To Provide

For a bug to be successfully fixed, the developer has a few things the he needs to know.

Although it is very important to give your computer's specifications and the software version that threw the bug, it turns out that it is actually more important for you to supply the following information:

1. What you were trying to do,
2. What you were doing before the bug occurred,
3. What you expected to happen when the bug occurred,
4. What you expected to see when the bug occurred, and
5. What you saw when the bug occurred,

Of course, just like a murder investigation, the more information you can take the time to give, the more likely a developer can fix your problem.

Remember that a developer has to be able to re-create the bug you saw in order to fix it, so if you don't give them enough information to make the same thing happen on their own computer, they will possibly just jump to the next bug in their bug list!

And Why You Should Give It To Them

Of course, the main reason why you should give all this information to them is because you want the bug to be fixed! But you should also realize that giving all of this information also saves both you and the developer time (and money in most instances).

For one, it usually takes you about the same amount of time to describe a bug up-front or after asked for details later, so being so brief doesn't actually save you any time in the long run.

By not giving the information up front, however, the developer loses quite a bit of time due to a bunch of small reasons, such as lost time in bug list triage, inability to group and collectively solve related bugs, and loss of time in having to contact users for details.

And, I'm not going to lie; commercial companies are driven by money. So if it is going to cost them money to get the details on a minor bug, they are likely to just bump it to the bottom of the list and go on to more important things. It sucks, it may even seem wrong, but I guarantee you every software company does it (and that you would do it too).

Last Words

If there is one last thing I want to impress upon you is that, despite all my harsh words for people that don't give details, having a bad bug report is still better than no bug report. We can't fix a problem we don't know about, and appreciate any information we can get. Just remember that it can be frustrating for everyone if you don't spend the extra two minutes of your life to give us some details.

Rant: Get Over It; Pluto Is NOT a Planet

Pluto is NOT a planet. Get over it.

For some reason, people seem to be offended that the International Astronomical Union stripped it of its ranks and recategorized it as a Dwarf planet.

And as a good scientist, I'm horrified how many people make their scientific decisions based off of raw emotions and no logics or fact!

That isn't to say that, in practice, science isn't driven by politics and emotions; but just because your immature little brother is being bad, doesn't mean you should as well.

So in order to set a good example to the emotionally driven ignorant masses, let's get to work on why Pluto cannot be a planet.

The Crux

The key to all of this is that there is no way to make a simple and impartial definition of a planet that includes Pluto with the other eight planets.

This is important enough to repeat:

There is NO simple, impartial definition we can apply to the word "planet" that includes the standard 9 planets, and only those 9 planets.

Lets Try Our Hand At This

Let's try our best to make a definition for planet that includes Pluto and see what happens:

So first thing first, let's try the most obvious definition. Let's try to limit by size. Since Pluto is about 2,400km in diameter, we'll try the following definition:

Definition #1: "A planet is any body bigger than 2,000km in diameter, whose primary gravitational influence is the Sun."

So now let's vet this one to see how it works out for Pluto.

If we consider the second part of the statement, "...whose primary gravitational influence is the Sun". As it turns out, depending on where Pluto is in its orbit, the gravitational pull between Pluto and Charon is somewhere between 40 and 110 times as strong as that of Pluto and the Sun! Thus the first thing we need to consider is a better definition of how the gravity of the Sun affects the orbit of the planet!

So let's try another definition.

Definition #2: "A planet is any body bigger than 2,000km in diameter, whose local system orbits the Sun, and who is not the satellite of another planet."

But whoops! It turns out that then we'd have to have 10 planets, because Eris--which was discovered in 2005--is a few kilometers bigger in diameter, and is almost 30% more massive--than Pluto!

Indeed, to put the size of things into perspective, it turns out there are seven moons of established planets that are bigger than Pluto, including our own moon!

Furthermore, there was no scientific reason why we chose a diameter of 2,000km as the minimum limit in the first place. It was just an arbitrary number that was pulled out of thin air in an effort to make Pluto a planet, but other similar objects not!

Indeed, if we tried to scientifically pick a minimum diameter, we'd probably want to pick the critical radius where gravity pulls the object into a spheroidal shape. This This diameter depends on the material of the body, but is often around 400km to 500km in diameter, which is about 5 times smaller than Pluto, and includes at least several Kupier Belt Objects, as well as the largest asteroid in the Asteroid Belt, Ceres!

Indeed, as we discover more and more Kupier Belt Objects, this definition could lead to dozens or even hundreds of planets!

So size (and mass) turned out to be a really bad way of defining what is and is not a planet.

So lets this another way entirely. What can we say about the orbits of the planets?

Well, let's look at how circular the orbit is; which is called its eccentricity. If we look at most of the planets, the eccentricity is such that the oribtal path is reasonably close to circular.

But this fails for Pluto. Pluto's orbit goes from around 30 AUs at its closest to the sun, to nearly 50 AUs at its farthest. Thus its orbit is nearly 1.7 times longer than it is wide making it pretty oval in shape.

But it gets worse. This test also fails for Mercury, whose eccentricity is almost as bad as Pluto's, while the asteroid Ceres has about the same eccentricity as Mars.

So if we try to use the shape of the orbit as a criteria, we endanger the planetary status of Mercury, while possibly allowing the asteroid Ceres as a planet!

So what if we look at the inclination of the orbit? Most of the planetary orbit's lie very nearly in the same plane as the Earth. In fact, most of the planets lie within 3.5 degrees of this plane.

However, this is very different for Pluto, whose orbit is inclined 17 degrees out of the Ecliptic Plane!

Even worse Mercury, at 7 degrees, has problems again!

It is inclined by over twice the amount of any other planet, and is getting pretty close to the orbital inclination of the asteroid Ceres, which is at about 10 degrees!

So once again, if we try to use an orbital parameter to define what is a planet, we endanger Mercury or include Ceres!

So it appears that we need to appeal to something else than orbit. Which leads me to wonder about Moons? Pluto has three moons, and all the other planets seem to have moons, while Ceres does not.

But wait; Mercury has no moons, while many other bodies in the solar system (such as some asteroids and Kupier Belt Objects) do. So this makes a horrible way of defining a planet as well.

An Analog From History

I keep bringing up Ceres for a reason. Ceres discovered in 1801, was the first asteroid found. However it was not always classified as an asteroid. Indeed, for about a half century, Ceres (along with the other three first found asteroids) were listed as planets in books and tables. Thus, for a good part of the 1800s, we had more than nine planets, and none of them were Pluto!

But as the number of astronomical bodies that all had nearly this same orbit grew, it became obvious that these were not best categorized as planets, but that they were best categorized on their own.

Indeed, this was a wise decision, as over the past 200 years the number of asteroids found has climbed over 100,000! Aren't we glad we don't have to learn about the 100,000 planets!

Kupier Has A Belt

So as it turns out, Pluto is smack in the middle of the Kupier Belt, and its only special attribute seems to be that it is one of the largest Kupier Belt Objects found so far.

Now since you are here, you probably don't know anything about the Kupier Belt. This is for good reason, because even though it had been conjectured to exist in the 1940's, it wasn't until the early 1990's that we were able to discover any object in it other than Pluto. Anyway, as a quickie overview, you can think of it much like an asteroid belt that is beyond the orbital distance of Neptune and upto 50 AU away. It contains thousands or even tens of thousands of objects, all in a similar orbit, and all with a similar chemical composition.

Indeed the composition of Pluto is much more like that of a comet, and the scientific evidence is mounting that many of the comets originated as Kupier Belt objects.

The Nail In The Coffin

Thus to continue considering Pluto a planet would be the same fallacy as having continued to cald the first four asteroids planets.

It would also mean coming up with an absurdly complicated definition of planet because we are too emotionally attached to what we knew

But since immediately after Pluto was found nearly 80 years ago, it has been conjectured that Pluto should not be called a planet because it doesn't belong with the others.

Good science is about progress, change, and admitting when we are wrong. And as we discover more about the structure of our solar system, we will have to continue to admit mistakes, change our definitions, and push scientific progress for the good of humanity.

Rant: Flame-War Fueling Language Reviews

One of my big pet peeves is people who start flame-wars over programming language choice. It is as if they think that they are righteous enough to force their one way of thinking about the narrow scope of tasks they solve, upon everyone else. Furthermore, it appears to me as if the majority of these arguments are fueled by the narrow-minded ignorance of those who do not take the time to actually understand the language that the proclaim to hate so much.

One example of this that sticks in my mind was a rant article I read in the early days of Java, which was written by a C++ aficionado. He spent a couple days learning Java and then proclaimed a long list of problems that Java had and why he would never use it. Although at the time his arguments seemed to make sense, I came back a year later to find that all his claims were actually based out of ignorance of Java, and that none of those problems actually existed if he took the time to learn how to think in Java instead of C++.

Now, one thing that seems obvious, but is frequently glazed over in language wars, is that not everyone is trying to perform the same tasks with the language they are using. This means that everyone requires something different out of the language they write in. Actually, now that I think about it, let me rephrase it: everyone requires something different out of the tools they write in, which would be the API. So just like you wouldn't use a hammer to plant your flowers or a rake to build a bookcase, different APIs are necessary to solve different problems.

Thus the way I see it, if you find a language that fits your personal style, you should be able to write anything in it, as long as there is a good API to support what you need to do. Thus a good API is the single most important place to discuss a lanuage, and only when it is in the context of accomplishing specific tasks.

So maybe what really is the problem is that people seem to have such strong opinions about a language when what they really should be discussing is the strengths and shortcomings of the API.

This would help keep away the all too often scene of petty complaints about the language itself, which are rooted in ignorance of how to leverage the language, and result in false arguments as to the righteousness of their own choice of programming language that are easily seen as flawed by those more knowledgeable of the other side.

But there is one other issue I'd like to discuss: if it is a matter of API only, why don't we implement Operating Systems in ruby, for example? Surely we could build a suitable base API for ruby and then build the rest of the OS in ruby itself?

Of course, the reason why we don't is that ruby is in a runtime environment that gives it the flexibility of platform independence and fast turn-around times, but lacks the speed necessary to accomplish such tasks efficiently.

But this isn't the fault of the language. No. This is the fault of the compiler/runtime. The langauge, which is just a grammar and rules for how to execute the basic constructs of said grammar, should be capable of performance at least on par with Objective-C, if not better.

Indeed, most languages, if they had a bunch of resources thrown at an optimized native machine language compiler, should achieve similar performance at runtime.

So when it comes down to it, when we review "languages", there are really three parts that need to be discussed, and each one needs to be discussed in the proper context:

1. API - Both the strengths and shortcomings.
2. Performance - As compared to other languages that can solve the same tasks.
3. Language - The kinds of people and projects that benefit and determent from the features of the langauge at hand.

So this brings me to one thing I have not discussed: The language itself:

Which languages you like is a matter of taste, and reflects upon you as a person. It naturally reflects on how you think and how you solve problems. But it also reflects on your ability to learn and adapt. Good programmers should always be learning and pushing their bounds, which always involves learning and understanding new languages. Unfortunately, too many people become comfortable in the one langauge they use and don't want to take the time to understand other languages. These same people, then, seem to always be the most vocal in the language flame-wars, usually displaying their ignorance to everyone in the process.

Expressing one's opinion is good, but people need to be more aware of what is their opinion versus what is fact; to be careful not to let their ignorance drive their zealous verbosity; and to support their viewpoint with calm and poise. Everyone is different and that is what makes life so rich and interesting. And while sharing ideas about what can make one language more useful than another is good, attempting to force everyone to conform to one way of thinking is not.