What do SQL and XSLT Have in Common?

Besides both making me angry and frustrated, what do SQL and XSLT have in common? They're both declarative programming languages.

Declarative languages express the logic of a computation without describing its control flow. This simply means that you tell the computer what you want the end result to look like instead of telling it how to perform the steps.

As I said, both SQL and XSLT are declarative languages. But so is HTML. I usually don't think about HTML as a program, but it is a set of instructions which tell the browser what to display. There's no way to express any kind of interaction with those components in pure HTML, which is why web development almost always includes JavaScript in addition to the HTML.

Imperative languages, by contrast, are concerned with the "how." In languages like C, C++, and Java, you are typically creating algorithms. You give the computer a series of steps that it needs to perform. If you want to display some text on the screen, those steps might be very difficult depending on a variety of factors. Compare that with "<p>Here is some text</p>" in HTML.

I won't tell you that one is better than the other. You should always pick the right tool for the job. But I will admit that I started programming in imperative languages long before I ever tried to use a declarative one, and the difference was often frustrating. Especially because languages such as SQL actually allow some imperative-style structure to sneak in. That enabled me to do things "wrong" because the wrong way was more familiar, and just set me up for total failure later when I tried to use XSLT.

Regular expressions are another example of a declarative language. Also another example of a language that I can never seem to get right, but I did find this really awesome tool for creating and testing them. I would highly recommend it next time you need to come up with one.

Amphibian.com comic for 3 November 2014

Why Do I Write Code in [insert language here]?

Starting this past Wednesday and continuing today (it will go on into next week if you must know), the frogs in my comic have hired some pythons to write software because they heard it was trendy. For the record, the Python programming language was named after Monty Python, not a snake, but that makes little difference when you are trying to select a language for a new project.

So the question is, do you pick a language to code in because it is practical or because it is popular?

And how do you even measure a programming language's popularity?

It turns out there are several groups that try to measure language popularity utilizing different methods. Take a look at the following...

• TIOBE Index
• Programming Language Popularity
• PYPL Index

So by most measures, Java and C remain very popular. It's important to see this in real objective data, because sometimes our understanding of programming language popularity becomes skewed by media attention. Often, languages that people talk about very much are used very little in production systems.

I found that all very interesting, but when I am starting a project (or re-starting, or upgrading) I try to pick the most appropriate language for the job. If there is more than one viable language for my system requirements, I pick the one that is most familiar to the team (which may be just myself). In other words, I tend to take a very practical approach to language selection.

Sometimes there is little choice. If you want to create an iOS application, your options are very constrained. This kind of specialization in certain product spaces is nothing new. When I was writing BBS Door Games in 1995, nearly all development was done in Pascal. I don't know why, I didn't really question those types of things back then. Of course, I only knew of 3 programming languages at the time...

Other times there is too much choice. If you want to build a web application, your options are nearly limitless. Personally, I have written REST web service applications in Java for a WebLogic application server and in JavaScript for Node.js. The JavaScript ones tend to be easier to write, but that doesn't mean that it's always the better choice. Knowing your particular requirements and the properties of a number of languages are the keys to making the right decision.

The take away from this is that if you want to be an extremely effective software engineer, you should be familiar with many languages and not be afraid to learn new ones. If you pick a bad one for a project, at least it's a learning experience. Don't make the same mistake again, even if it means learning something completely new.

Amphibian.com comic for September 26, 2014