Thread: knowledge programmers must have? where should I go from here?

I didn't intend to start a war on language in this thread, but since NB has been showing up in posts (and it was even used in an article on cprogramming.com) I became increasingly annoyed at myself for not knowing what it was. I hate acronyms -- because they are confusing for me. I guess other people are really good at picking up this stuff but I've had to look up everything from ie to eg to etc to sic at one point. Shorthand is impossible. So if there's abbreviations in English for borrowed phrases like that, it becomes too much for me.

Now I'm embarrassed but at least I'm not so ........ed off anymore.

Originally Posted by MK27

...


/:?

What are you confused about?
It's easier to talk about a refrigerator if you know its name.
However, you don't need to know how exactly it works (its formal definition) to understand what it does (keeps my wares from rotting).

It's easier to talk about a refrigerator if you know its name.
However, you don't need to know how exactly it works (its formal definition) to understand what it does (keeps my wares from rotting).

But refrigerator is the English name for a machine to keep things cold. Definitions almost never go into how something works; they talk about what it is.

Originally Posted by Elysia

What are you confused about?
It's easier to talk about a refrigerator if you know its name.
However, you don't need to know how exactly it works (its formal definition) to understand what it does (keeps my wares from rotting).

Okay, I see your point now but I'm going to have to side with whiteflags about the relationship between definition and name. A name is almost useless without a definition. How something works is not the definition of what it is, although the later may be somewhat included in the former, and "how it works" regresses. Eg:

Originally Posted by wikipedia

Bubble sort, also known as sinking sort, is a simple sorting algorithm that works by repeatedly stepping through the list to be sorted, comparing each pair of adjacent items and swapping them if they are in the wrong order.

Name
Definition
How it works

If "bubble sort" were instead called "refrigerator", the name would provide no clue about the definition, as many words do not (I think "refrigerator" actually does contain some clues about the real definition). In this case, you would have no idea what a refrigerator was, without context, (example of context: "Next, we sort the list using refrigerator").

Think also of qsort() as a name/identifier. The definition of qsort might include "using the quicksort algorithm", which is sort of how it works (so the regress is, "but how does quicksort work"?) and would not be necessary to a minimally functional definition ("using a fast sorting method" or just plain "arranges in a sorted order" makes sufficient sense).

Look up some common machines in a non-encyclopedic dictionary and decide the extent to which "how they work" is included in the definition.

Originally Posted by Elysia

What are you confused about?
It's easier to talk about a refrigerator if you know its name.

So if I were in an interview and someone said, "Let's talk about binary trees," and I have never heard of such a thing before, I'm now good to go because I know the word for what we are talking about is? Sounds like an episode of Fawlty Towers

I'll pick a much better example.
Can you describe a list (not std::list, but a list data structure such as in prolog and erlang)?
Can you name its formal definition?
Do you need to know the formal definition to understand what it is?
Does knowing the formal definition on how it is help you in practice?

Ah, semantics.

Originally Posted by Elysia

I'll pick a much better example.
Can you describe a list (not std::list, but a list data structure such as in prolog and erlang)?

And how is that different from saying, "Can you define list for me?".

Can you name its formal definition?
Do you need to know the formal definition to understand what it is?

I have no idea what the significance (or definition) of "formal" is here -- as in, using correct grammar and punctuation?

Yes, you do need a definition for a word in order to understand it. It doesn't matter where you get it or how "formal" it is as long as it is correct.

Also: you are using "thing" and "name" as if they were synonymous. If you have a hammer, is it useful without a name or definition? Of course. But if you don't have a hammer, you need a name and a definition in order to discuss it.

Does knowing the formal definition on how it is help you in practice?

Of course it does, much more so than the name. You don't need to know the name "camshaft" in order to replace one, but I absolutely promise you need to know the definition of what a camshaft is (even if exactly how it works is not completely clear).

Originally Posted by CommonTater

An excellent example of "name does not define function" comes from some of the earlier program names in Linux... Tin, Pine, Wood, etc... yeah that's really gonna help me sort it out...

I think you mean unix, since that's where they came from. The world's first e(lectronic)mail client was elm, hence, if you knew what elm was, pine makes sense. But what the hell is an "outlook"?

Pretty much all of the *nix core system utilities have very utilitarian names, either simple pseudo acronyms/abbreviations (sed, grep, cat, cd, ls, chmod, etc) or just plain words (cut, more, who, apropos, whereis).

Originally Posted by MK27

And how is that different from saying, "Can you define list for me?".

I can define, or describe it to you: it is a sequence or set of n elements.
But that is not a formal definition. But it is enough to understand what it is.

I have no idea what the significance (or definition) of "formal" is here -- as in, using correct grammar and punctuation.

No, that is not it.
Our spoken language is ambiguous. Its meaning depends on context, and even with proper context, it can still be ambiguous.
But computers cannot understand such language. They require an unambiguous language. Hence, we need "formal definitions" of something for a computer to understand something.
A computer is not going to understand what a set of of n elements means.
I could attempt such a format definition for you.

For example, a formal definition of a list in Prolog might be:

[a] - This is a list with one element a.
[a | T] - conjugate(a, [T]).

Nothing else is a list.
What this says is that if there is something that looks like [a], then it is a list with one element: a.
If, on the other hand, the syntax looks like the second row, then it is a conjugate of the element a and the list T.
This makes the syntax [a, b, c, ...] a valid list too, sine it would match [a, [b, c, ...]] and hence makes use of a recursive definition.
(This is my best attempt at a formal definition; it might not be fully right by any means.)

Let's take another example.
What is money? Well, it's the paper things we use to buy stuff with, right? That much is obvious. But that is not a formal definition of the word.
I took a formal definition from a site, and here it is:

A medium that can be exchanged for goods and services and is used as a measure of their values on the market, including among its forms a commodity such as gold, an officially issued coin or note, or a deposit in a checking account or other readily liquefiable account.

Do you have to know that definition to understand what money is, though? Will it do you any good in practice to know that definition?

Yes, you do need the definition of a word in order to understand it.

No, you don't. You need to understand what it means, but that can be different from its formal definition.
We do typically use words everyday without understanding what they truly and fully means. We understand them enough to put them into practice, but can you quote someone who knows what all the words mean exactly? I think not.

Of course it does, much more so than the name. You don't need to know the name "camshaft" in order to replace one, but I absolutely promise you need to know the definition of what a camshaft is.

You need to know what it is to replace one. You don't need to know its formal definition.
But if you don't know its name, it can be difficult to converse about it.

Originally Posted by Elysia

I can define, or describe it to you: it is a sequence or set of n elements.
But that is not a formal definition.

It's still a definition.

computers cannot understand such language. They require an unambiguous language.

Computers cannot understand anything in the sense that we understand things, no matter how formally or unambiguously defined. Including:

For example, a formal definition of a list in Prolog might be:

[a] - This is a list with one element a.
[a | T] - conjugate(a, [T]).

The computer does not understand that (or need to) any more than a hammer understands a nail.

What this says is that if there is something that looks like [a], then it is a list with one element: a.
If, on the other hand, the syntax looks like the second row,

Blah blah blah. This is just a more technical definition applying some formal logic.

Let's take another example.
What is money? Well, it's the paper things we use to buy stuff with, right? That much is obvious. But that is not a formal definition of the word.
I took a formal definition from a site, and here it is:

At this point, your distinction between "formal" and "casual" definition becomes ad hoc and largely about style.

Do you have to know that definition to understand what money is, though? Will it do you any good in practice to know that definition?

Again, the "in practice" conflates a thing with its name. You do not need the name of money either, in practice.

THE NAME IS NOT THE THING. THE NAME IS NOT THE THING. THE NAME IS NOT THE THING. This is elementary.

You need to understand what it means, but that can be different from its formal definition.

What??? The definition is just the statement of the meaning. If you know the meaning, you can state a definition for a word. If not, the word is meaningless to you.

Originally Posted by dictionary.com

def·i·ni·tion

1. the act of defining or making definite, distinct, or clear.

2. the formal statement of the meaning or significance of a word, phrase, idiom, etc., as found in dictionaries.

Interesting use of the word "formal" there too.

You need to know what it is to replace one. You don't need to know its formal definition.
But if you don't know its name, it can be difficult to converse about it.

What kind of conversation are you going to have using a word you cannot define? And by define, I mean, "state the meaning formally" (as per the definition of definition above). If you can't do that, you don't know what the word means, and if the person you are talking to does, s/he will know you for a fraud (or clown). Period.

Go find someone and talk to them about an odradek. If you don't know what that means, you can always ask someone for the definition.

I already stated my thoughts and expanded upon their meaning. I find their meaning truly unambiguous now, so I am not going to pursue the matter further.
Debate the semantics and the use of words properly/inproperly all you want. I think the concepts, what I actually meant to say, now stands clear, even though my choice of words may not have been the best in some eyes.

.T_T.

Originally Posted by Elysia

I already stated my thoughts and expanded upon their meaning. I find their meaning truly unambiguous now, so I am not going to pursue the matter further.
Debate the semantics and the use of words properly/inproperly all you want. I think the concepts, what I actually meant to say, now stands clear, even though my choice of words may not have been the best in some eyes.

Well, it's nice to know you've stopped listening. I think what MK27 and I are trying to say is that there can be several definitions of words, because to formally define a word is to pick a meaning for the purpose of discussion. You do that all the time. When you wrote this post,

I'll pick a much better example.
Can you describe a list (not std::list, but a list data structure such as in prolog and erlang)?
Can you name its formal definition?
Do you need to know the formal definition to understand what it is?
Does knowing the formal definition on how it is help you in practice?

The answer to all of these are yes. In fact, you wrote enough to let me know that you wanted to discuss the meaning of list as it pertains to computer science; which is as formal as any implementation. In fact I think your plan was to pick a language I might not know, to confuse me and control the conversation. Like MK27 said though, the name is not the thing. Definitions are concepts.

Some words are also truly unambiguous, like "assay", but that doesn't have a lot to do with the rest of it.

I'll just add that while I agree that you don't need to know neither the name of a thing nor the formal dictionary definition of the name of the thing, it is possible to understand what the thing does or what it is used for.

for example, I didn't know until recently that in java & C# the syntax { } is a statement, and is named "block".

It's good to know that the 'thing' used to enclose groups of code is considered a statement, and it's also good to know that it has a name, but it could have been called giraffe and I still would have used it the same way.

By the same token, if I had not known that { } is considered a statement, it wouldn't have made much of a difference, just like it wouldn't have made much of a difference if I hadn't known that { and } are considered punctuators, which are considered tokens, which are considered lexical elements, which are sequences of unicode characters that have some meaning to the compiler.

Nevertheless, I can see why if an interviewee can't explain a concept, the interviewer should be worried about hiring that person. Perhaps the interviewer is not an idiot who doesn't know that neither the name of the thing, nor the definition of the thing, nor the classification of the thing, are the same thing as the thing. But perhaps he or she is concerned that the interviewee, if hired, won't be able to communicate his understanding of programming with other programmers and possibly not even with non-programmers.