Does programming terminology have an inbuilt tendency away from clarity?

Question

A little while back I decided to learn C# which has been a fairly rewarding experience as the language seems very easy to pick up.

That is, with the exception of the terminology. It's not that there's loads of jargon (that comes with learning any new language/technology) - it's that the terms used seem to be either awkward, unclear or unnecessarily complex. An "array" seems like quite an easy thing to explain to someone because of it's name alone, compared to (say) IEnumerable collections.

But this is beyond a specific language/platform. Take the below:

• functions/subroutines vs. methods
• errors vs. exceptions
• temporary tables vs. common table expressions
• user owned tables vs. schemas (in SQL Server)

I appreciate these aren't exactly equivalent terms but the "original" terms just seem to fit better and are therefore arguably easier to explain or understand.

So ... Are all the "good" names for things already taken?

Or are the concepts simply becoming more complicated and therefore more distant from day-to-day language. Are there counter-examples to this trend? (Obviously there are lots of tasks which are much simpler, but this is generally the result of an external library/the OS/etc doing things which a programmer previously had to do, rather than the same work being better described).

Or am I utterly wrong and my mind is simply warped from learning BASIC as a kid (as per Dijkstra)?

Answer 1

Much of the time the terms seem confusing because they are meant to describe the language feature as explicitly as possible.

For example, an Error is not semantically the same as an Exception, thus we need to have different terms to describe them. If we called all Exceptions Errors, what word would you use to differentiate an Error from something like an IllegalArgumentException?

Answer 2

Every domain of knowledge tends to develop jargon so that domain-specific concepts can be discussed without labouring over the language used to express those concepts.

When I was taught data modeling it was emphasised that a key to developing a good model was to understand--document if helpful--the domain vocabulary. I certainly found this to be true, with the side benefit of helping me relate to the users of the system, understand their difficulties, and see possible solutions that I would not have seen without this deeper understanding through language.

If you stay with a domain long enough these words become as familiar as the rest of your vocabulary, and then the challenge is to hold normal conversations without sounding like a geek. ;-)

Answer 3

Or am I utterly wrong and my mind is simply warped from learning BASIC as a kid (as per Dijkstra)?

Yes that is likely the reason.

Answer 4

I think it very much depends on the development community.

PHP for instance is pretty much jargon free. This is probably because the php community is interested in getting pages to the browser rather than thinking about something "original" to put in thier thesis.

Perl has its very own strange but clear jargon ("bless this object"?) which is probably a reflection of both how articulate and quirky Larry Wall is.

C++ and Java are probably the worst offenders for "inventing new words for a wheel". "Persistence" is probably the worst example; did we really need another terminoligy for "write to file". This is probably due to the large number of Java/C++ comminity members who are trying to think of "original' topics for a these rather than how to get pages out to a browser.

Answer 5

Most of these words don't have the exact same meaning. If you take the function vs. method example:

A function as I understand it is something standing alone using an imperative language like C or a JavaScript function that is not associated to an object.

If you use the term method instead you are already implying that the language you are using is object-oriented and that you are oparating on an object.

Answer 6

Programmers love words. We get paid a lot of money to put them in the right order and make "magic" happen. So it's only natural that we describe what we do with excruciating detail. Programmers usually mean exactly what they say.

As you've said, all those terms aren't exact synonyms they each mean something different. For instance, "list" (to me) implies a linked list where I can have duplicate values. An "array" implies I can't have duplicate values. Other language folks would disagree with me here, causing the opposite of what we want in communication: parity of ideas.

Even the fact that I said "parity" illustrates the problem here. Basically the more obscure the word, the more precise its meaning. "Car" means several things to several people, but "aileron" means pretty much one thing.

I think language designers and authors strive to pack all the semantic meaning they can into their terms, but they just aren't obscure enough.

Too much "overloading" :)