Programming Languages Terminology – Difference Between HTML and C++

What is the difference, really?

The real and important difference between a programming language and these other languages is this:

HTML and CSS describe presentation, whereas programming languages describe function

I intend to illustrate why this difference matters, but that pedantry on this issue is sometimes misplaced.

A true story:

I once spent a few months developing a complex performance management system using a "proper" programming language. It automated the process of gathering data from various other systems, performed various manipulations on that data and then presented the results in a simple table.

Once it was live, a senior manager saw a tool written for a similar business, and asked if we could replace what I had written using their alternative. Furthermore, he was upset that I'd spent weeks developing my solution, where this new app had been written in a matter of days.

Further investigation revealed that the manager's preferred option was all presentation with no substance: there were lots of colours and icons and graphs, but there was absolutely no logic behind them. All the data had to be gathered and manipulated manually. Despite the pretty interface, the application was essentially useless.

I'm happy to say that the manager in question was persuaded that my approach was the one that met his real business needs.

The importance of presentation:

There is often an implication that skills in HTML, CSS etc. are somehow inferior to skills in "real" programming languages. This is a serious mistake.

In my story, the senior manager felt that design was very important to him, to the extent that he was initially prepared to overlook function in its favour. Now, if this were an isolated incident, I might suggest that the manager was just being silly. But it wasn't. Time and again, I've met users who are impressed by flashy graphics and whizzy widgets, but unimpressed by raw functionality and my technical achievements. I think that there are several lessons to learn here:

• People evaluate software on criteria that they understand. They often understand the difference between good-looking and ugly, but rarely appreciate technical nuances.
• People are fooled by appearances. This may not be a good thing, but it is a reality that we must live with.
• Appearances influence the way people feel about software. The way people feel about software is important to them. Indeed, people sometimes prefer software that makes them feel good over software that is functionally superior. Indeed, they might well be more productive with feel-good tools than with technically superior tools. To this extent, our users are not being fooled. They are actually making a wise and thoughtful choice.
• As programmers, we often neglect the role of presentation as we focus on function. To some extent, this is right and proper. However, it is important to recognize that there is another dimension to our work that is important to our customers.

So, presentation-oriented languages (HTML, CSS) are important. The value added by those who can use these tools effectively should not be underestimated.

The importance of real programming languages

As the OP pointed out, "real" programming languages are Turing Complete. As a proper sad geek, I find this sublimely fascinating. It means that, for any program written in a T-C language, a functionally equivalent program can be written in any other T-C language. Of course, this isn't to say that all languages are the same. They each have their strengths and weaknesses that make them more or less suitable for certain tasks. However, I/O aside, this means that all programs can be written in all true programming languages.

(Incidentally, the important thing is T-C. The declarative vs imperative is a red-herring here. SQL, for example, is declarative but is also a proper programming language because it is T-C.)

Of course, the same isn't true of a markup language like HTML or CSS. In fact, there are whole classes of problem that these languages simply can't solve. Where I can program anything I want in a true programming language - including layout engines - it just isn't possible to achieve the same things with languages that aren't T-C.

As highlighted in my story, HTML and its ilk are used to produce presentation. Real programming languages are used to produce functionality.

Why are programmers pedantic about it all?

1. Programmers spend a great deal of time, effort and money developing their skills. People naturally value the things in which they invest ("your heart is where your money is").
2. Programmers often feel the need to justify the amount of time it takes to produce results compared to the rapid results achieved by UI designers. In order to do this, they need to draw a distinction between what the two groups actually do.
3. Because employers need to apply the right people to the right jobs. Unless we clarify the (often technical) differences, managers easily make the wrong calls.
4. Because there is a real and fundamental difference, as outlined above.

Is it always appropriate to be pedantic?

Let's face it, as programmers we're a naturally pedantic lot. It goes with the territory. It doesn't help that many of us have been burned when non-programmers have failed to understand what we do.

Nevertheless (and to be honest, this goes against my natural instincts), I don't think we need to call people out whenever they slip over every little distinction.

The important things here are context and perspective.

I'm told that, from the perspective of a biologist, a tomato is a fruit. But when I buy them in the supermarket, I look for them amongst the vegetables. Why? Because the technical distinction doesn't matter in that particular context. Moreover, the distinction would actually get in the way of their usefulness: if I was daft enough to include tomatoes in a fruit salad, for example.

It is the same with computer languages. There are times when the difference between programming languages and other languages really does matter. Quite often, however, we can all communicate perfectly effectively when just lump them all in together. In the case of the question linked by the OP, it really didn't matter what languages were true programming languages and which were not. Pointing out the distinction didn't advance the discussion in any way. Thankfully, other than adding a little noise (and becoming the stimulus for an interesting discussion!) the pedantry linked by the OP was of little consequence. At its worst, however, pedantry can stir up negative feelings and damages relationships... at least according to my wife.
:-)

How to deal with pedantry amongst programmers

A preacher friend of mine once delivered a sermon entitled:

is this a hill worth dying to be on?

He was referring to generals who make a strategic assessment over which battles are worth fighting: are the gains worth the costs?

• Is it really worth interrupting the flow of the discussion to make this distinction?
• Does my pedantry stem from a sense of arrogance or from past hurt?
• Do my comments value the skills of others as well as my own?

Of course, there are times when distinctions need to be made. My aim is that, when I make a contribution, it will add value to our collective endeavors.

That is, after all, the job of every real programmer.

I generally try and describe Object-Orientated-Programming by using real world examples.

For example, I might say that a class called Vehicle describes the minimum things that a vehicle is. I'll ask the person to tell me what he or she thinks a vehicle is. Sometimes they say things like "Well, like a car or a truck", and I'll nod and agree with them. Then I'll ask what the differences are between a car and a truck. Sometimes they mention size, sometimes the purpose, and other things.

Then I'll ask them to forget about a car, or a truck and just ask them to continue to describe a vehicle:

"Oh, well it moves"

"It has an operator, or a driver"

etc...

Soon, we know what a Vehicle is and I said that in OOP we would define a vehicle, and for the sake of argument say it can move, and give it a driver of sorts. Then I'll ask, ok, so what does a Car have?

"Doors"

"Windows"

And then a truck....

"Doors" "windows" "More Wheels!"

Soon, after lots of discussion, the other person generally has identified:

1) What constitutes a vehicle

2) What constitutes a car

3) What constitutes a truck

4) What constitutes an aeroplane.

All without any technicalities. We've divided up the properties of each in to the right areas. They understand inheritance ("Yeah, a car is a vehicle, a truck is a vehicle, but a car is not a truck, it's SIMPLE, duh!").

They even understand polymorphism, "Sure, they basically do the same, but that might do it slightly different.". We can talk about behavior and where that should live in our tree of objects.

Depending on their education and background, some get it faster than others. But when I compare OOP to real-life objects, most people always get it. In fact, I have found in conversations with non-technical people things I had never thought of. Vehicles don't have to be manned, for example (drones), but would a programmer have thought of the operator of the vehicle as a property of it? I am not saying it is right or wrong to have an operator mentioned, but it causes us to think about what we are modelling and what we are trying to achieve when we develop software.

Now, partial template specialization, on the other hand.... :)