Comparing Programming Languages and Tools

Since the Dev Practices posts are scheduled so far out, sometimes I forget which ones are added and which ones are running on what day. It makes it all the more fun to run the site, but I digress.

One ran the other day that, although I thought was funny, was more “funny because it’s true” and less “funny, haha” or “funny, weird.”

tools-v-tools

How many of you have found yourself in some type of conversation that escalated into an argument about comparing programming languages and tools and who’s set is better when all you were initially trying to do was to share what things you enjoy using in your day-to-day?

Comparing Programming Languages

When it comes to development, I like to believe that people generally have good reasons for the tools that they use. Sure, sometime people use them because they don’t know of any better options; others, on the other hand, use them because they find them helpful, easy-to-use, and are generally more productive than with the alternatives.

For example, when writing JavaScript, it’s relatively common among developers to use a linter such as JSLint or JSHint. The idea behind each of these tools is that it helps us to write higher quality JavaScript.

But there are some developers who aren’t familiar with those tools not because they don’t want to use them, but because they don’t know they exist. You can’t fault anyone for that.

But if you are aware of them and you write a lot of JavaScript, then why not use one?

I think that wherever the area of debate ensues between what tools are best and why may ultimately hit a limit to where the outcome may not matter.

Sure, a full IDE is better than, say, using TextEdit but if you’re comparing two similar products (and an IDE and TextEdit is not that) then I think it comes down to how skilled a developer is with his or her given toolset.

  • Do they know the shortcuts?
  • Do they take advantage of the built-in features?
  • Are they able to set breakpoints and step through code while watching variables?
  • …and so on

I think there is something to be said for teams using the same set of tools when working on the same piece of software, but that’s the content for another post.

Rather, whatever your set of tools are, know them inside and out and become as proficient as possible with them. It’s not so much about trying to one-up anyone, and it’s not so much about trying to convince anyone else why your set of tools is better than any others. It’s about being as productive as possible given the set of tools that you use.

If another set of tools comes along that helps you be more productive, then try it out. But don’t blindly try something just because it sounds like it’s the next best thing and because everyone seems to be using it.

Instead, evaluate it, see how it fairs, and then make the change only if your productivity and your general enjoyment of using said application increases.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.