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

I was doing simple programming, fixing things and never really building or designing anything, and I was using proprietary technology, so that experience was pretty useless when it came to finding another job. I'm currently learning C#/ .NET and hope to obtain a job doing .NET web or desktop development (or at least a job where I will be working with these technologies).

what I want to know is where I should go from here, given that most of the formal programming education I have received is limited to a handful of freshman level courses. I need guidance trying to understand what subjects I'm better off studying during the next 4-6 months, in the interest of returning to the labor force, catching up with computer science majors, and, of course, my own personal satisfaction.

Let me put it this way: I actively try to deepen my knowledge of C#, .NET and object-oriented programming in general, and the harder I try to find answers, the more questions that are posed before me. I feel that even though I have acquired knowledge of a core set of programming-related concepts, I still don't know enough.

For example, am I better off expanding my knowledge of everything that goes on behind the scenes, and learning to work with pointers and memory addresses, and manipulating data at the binary level, possibly using an assembly language, or am I better off learning all the intricacies of concurrent programming?

Am I better off learning design patterns? Or studying and memorizing 'basic' algorithms and maybe some more advanced ones as well as trying to come up with some of my own?

Or am I better off continuing to deepen my knowledge of C# and .NET, and learning as much trivia as possible? (ie: not possible to have a constant field of non-built-in struct type!)

Or should I learn as many .NET API's as possible?

Or should I continue to learn about Windows programming? (ie: learning to create applications that make use of the registry and so on?)

Or should I stick to making web sites and GUIs with fancy controls and lots of eye candy?

Or am I better off learning as much SQL server as possible?

(I know there is probably no right or wrong answer here, but my guess is that some paths are likely to be more 'useful' than the other ones when it comes to becoming not only a competent programmer, but most importantly and at least for the time being, employable.)

Memorizing APIs don't really help much. Anyone can look it up when they need it, and employers know that.

What they want is problem solving skills. You can't just Google for that.

How about making a big project that showcases your skills, that you can be very proud of?

Quote:

---

Originally Posted by cyberfish

Memorizing APIs don't really help much. Anyone can look it up when they need it, and employers know that.

---

That's true. But many of the times I've been to job interviews I've been asked general knowledge questions such as whether I know what an abstract class is, or a stack, etc.

Back in the day I miserably failed a lot of those interviews, since I devoted most of my brain power to problem-solving and never bothered memorizing textbook definitions. That's when I learned that if I can't explain what I supposedly know how to do, most employers are unlikely to conclude that I know how to do it, and since their opinion is what matters, I might as well give them what they want.

For example, I can write recursive functions, at least basic ones, but the only way I can explain what recursion is is by spitting out a memorized textbook definition, because if I try to explain it using my own words, I'd have a really hard time coming up with something more detailed than 'a function that calls itself'.

And that's why this time around I rarely bother with actual problem solving and instead spend a good chunk of my time thinking about the way all of the tiny details fit into the bigger picture and how I would go about explaining these concepts the day of the interview.

Quote:

---

How about making a big project that showcases your skills, that you can be very proud of?

---

I definitely need to do that. I guess the only part I have trouble with is the word "big". For the purposes of getting hired to do an average entry-level programming job, how "big" should a sample project be? I guess you could say the bigger the better, but I have a limited time frame and there is only so much I can do in a limited time frame.

Also, I think that one of the biggest obstacles I need to overcome is lack of creativity and lack of ideas. I mean what can I do that hasn't been done already? well, I guess there are many things that haven't been done already, but if they haven't been done it's probably either because they don't need to be done or because they are so complex nobody has been able to do them.

Maybe I should just continue acquiring knowledge for now and work on something on the side.

But i still want to know what's more important when it comes to the average entry-level programming job, being able to, for example, do concurrent programming, or understanding memory addresses and the binary representation of data, and so on?

well yeah, everything else being equal, the programmer's iq is probably what's going to set him apart from other programmers, but how about the actual programming / computer science knowledge I should have if I want to diminish the likelihood that my next job interview will end prematurely?

A proof of ability piece as suggested, will carry you a long way in a job interview. It doesn't have to be anything particularly big or fancy, just prove that you can do the basics... navigate files, change values, edit text... maybe something like an alternate to Windows Explorer or a Network Browser that actually works (even Microsoft has trouble with that one). If you give them the familar, but better, you will impress them... give them something they won't understand --the answers to project Euler for example-- and they'll feel disconnected from the screen and the impression may fail.

Much to my chagrin, programming seems to be heading down the C++ path almost exclusively. Most of the ads in my area are looking for C++ or Web Design, very few are seeking .NET or C... So you might want to give some thought to getting off the "platforms" and going with native code and it's many advanced powers. For a certainty being able to honestly say you know 2 or 3 different languages will be a big plus.

And the point made that a programmer's most important skill is problem analysis and solving is dead on the money. If you are going to climb into this as a career there's no way you can have those skill too highly developed... and yes, it does take an above average IQ.

Quote:

---

Quote:

---

Originally Posted by cyberfish

Memorizing APIs don't really help much.

---

Quote:

---

Originally Posted by y99q

That's true. But many of the times I've been to job interviews I've been asked general knowledge questions such as whether I know what an abstract class is, or a stack, etc.

Back in the day I miserably failed a lot of those interviews, since I devoted most of my brain power to problem-solving and never bothered memorizing textbook definitions.

---

---

Textbook definitions are important because they allow people to communicate in a reasonably objective manner. IMO, they also help you to keep things straight in your head. Of course, there are people who prefer to work "intuitively" and that doesn't (by definition, lol) mean they are bad at something, just as knowing the correct definitions won't make you good at it. I'm sure there are (a few) people out there who can take a car engine out, dissemble and overhaul it, and put it back together again in better condition than it started, but still not be able to name half the parts.

However, while being able to recite textbook knowledge is not necessarily a sign of competence, if you took your car to a professional mechanic, and in the course of discussing your problem it became clear that the mechanic could not name parts of the engine properly, would you feel comfortable leaving it with this person and then paying him/her thousands of dollars to get it back later?

If you want to be a professional, maybe being able to apply textbook definitions will count as a positive. Here's an example for you: cyberfish says, "Memorizing APIs don't really help much", and you say, "But many of the times I've been to job interviews I've been asked general knowledge questions such as whether I know what an abstract class is, or a stack, etc". When I first read that, my immediate response was that this was an unintentional non-sequitur, and that this person does not know what an API is, because it is not about "general knowledge questions such as whether I know what an abstract class is, or a stack". One of those two distinct things is probably much more important in an interview than the other. I think you do know the difference, but you talk casually as if you do not, which is probably a bad habit. Or have we mis-communicated? ;)

Quote:

---

I can write recursive functions, at least basic ones, but the only way I can explain what recursion is is by spitting out a memorized textbook definition, because if I try to explain it using my own words, I'd have a really hard time coming up with something more detailed than 'a function that calls itself'.

---

Well, as long as you understand whatever the textbook definition is and can apply it, why not just stick with it? Again, the purpose is communication, not for everyone to come up with their own personal definition (to seem creative or intuitive or something).

I think you need to come up with a project of your own that you are interested in, that you can take seriously and be enthusiastic about, that you can put some daily work into so in a few months you can look at it and go wow, look, I really can do this. By nature, no doubt, it will involve learning some new stuff that will have some general applicability and sharpen your skills, etc.* Even better if it is along the lines of what you would like to do professionally. I don't hire people, so I don't know how much that kind of thing counts with employers, but I can tell you that I have gotten work from people by saying to them, look, I although I've never done X and Y professionally, I've done something along those lines on my own time out of pure interest, and look, here's the result, judge for yourself.

Plus it helps keep you sane. Rather than sitting on the bus worrying about your life (which quickly becomes worse than pointless), you can sit on the bus and think about what you're gonna do when you get home (besides watching TV, hint hint).

* and, nb, I'd think that while demonstrating knowledge of some specific API may not be that interesting to an employer, being comfortable learning them (reading definitions and applying them competently, ie, being able to do research and learn quickly and independently) probably is. That's a practice. So yeah, learning an API that has use value for you -- say, in a project -- has to be a good thing.

And for anyone who is confused, I just found out that NB is an abbreviation for a phrase in a dead language called Latin for "note well". Just in case that bothered anyone else for ages.

Quote:

---

Originally Posted by whiteflags

And for anyone who is confused, I just found out that NB is an abbreviation for a phrase in a dead language called Latin for "note well". Just in case that bothered anyone else for ages.

---

I think it is the same in Italian ;)

BTW, eg and ie are all old latin too. Either that means the language is not so dead, or else we need to come up with new versions of eg and ie. I guess we should use English for that, because it is the new universal language. So I say, patriots of (post) modernity, reject these anachronisms! From now on, instead of eg, fe ("for example"), instead of ie, iow/ti ("in other words/that is")!!

Meh, WTF.

ps. I actually use all of those in conversation too, eg, "N B -- the pan is hot! I E you can get burned!" xP

Quote:

---

Originally Posted by MK27

I guess we should use English for that, because it is the new universal language.

---

Don't let the aliens here you saying that.
I think we should do away with languages and use numbers for everything ! ...but nobody will agree on which number to denote what ..

Quote:

---

Originally Posted by manasij7479

Don't let the aliens here you saying that.
I think we should do away with languages and use numbers for everything ! ...but nobody will agree on which number to denote what ..

---

Speaking strictly as someone who's handwriting has been likened to Klingon Secret Code...

Textbook definitions are definitely not as important as some make them out to be. Knowing them won't make you smarter.
These definitions are simply formal definitions stating exactly what something is and what something isn't, and the reason we have them is because our spoken language is extremely ambiguous.
Sure, you can show off to your pals by bragging about how you know many definitions, but that's hardly going to be much of use in the real world. What is important is that you understand a concept, what it is, how it is used and what limitations it has.
Knowing the name of something (important) is not the same as knowing the definition of something (not so important). Separate those two concepts.

Quote:

---

Originally Posted by manasij7479

Don't let the aliens here you saying that.
I think we should do away with languages and use numbers for everything ! ...but nobody will agree on which number to denote what ..

---

Numbers are a subset of language. What meanest thou, hexadecimal?

Quote:

---

Originally Posted by MK27

Numbers are a subset of language. What meanest thou, hexadecimal?

---

The plan is to invert it... make languages as subsets of numbers ! ....and how you express the numbers is up to you.

Quote:

---

Originally Posted by manasij7479

The plan is to invert it... make languages as subsets of numbers ! ....and how you express the numbers is up to you.

---

When you express numbers, you have to do it an a language. To convert languages to numbers would be frivolous, considering you'd have to convert the numbers back in to a language to do anything with them.

Now I'm confused.

...

Quote:

---

Originally Posted by Elysia

Knowing the name of something (important) is not the same as knowing the definition of something (not so important). Separate those two concepts.

---

/:?

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.

Yeah I wouldn't be surprised if a significant number (90%?) of three letter combinations are TLAs.

Quote:

---

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).

Quote:

---

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.

Quote:

---

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:

Quote:

---

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.

Quote:

---

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?

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...

Ah, semantics.

Quote:

---

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?".

Quote:

---

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.

Quote:

---

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).

Quote:

---

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).

Quote:

---

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.

Quote:

---

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:

Quote:

---

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?

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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:

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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,

Quote:

---

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.

Quote:

---

Originally Posted by whiteflags

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,

---

Did you see MK27's reply? It seemed more like it would start a flamewar if I replied to that instead of a discussion. That's why I stopped doing it.
I have noticed we seem to use different words for different purpose, and that is the meaning of unambiguous. Nevertheless, I do think I explained what I used the words for. How I "defined" the words.
I don't see a point discussing the definition of the words "definition" and "formal definition".

Quote:

---

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.

---

Also consider this.
Sure, all knowledge have some sure in some way or form. But the question is, how often do you need it?
There might be a word you use everyday. There might be a word you use only once a year.
This is kind of the same situation with knowing a formal definition, a "casual" definition and a concept's name.
Sure, a formal definition might do you some good some day, in some way. But it is probably not as important as knowing the name of the concept which you would use far more often when speaking with other programmers and other people.

I tend to separate things into three categories: name, casual definition and formal definition.
The name is as its implies. But knowing only the name won't make you understand what something is, but will help you discuss that with other people.
Casual definition is basically what I mean as knowing what something is and being able to describe it in your own words. This is absolutely critical. without it, you won't understand what something does.
Formal definition is what I mean by knowing the exact way something is defined, written down some place or some where. Like how a set is described in a mathematics book. This is typically less important, however, since you will be able to use and understand something with its casual definition often without the need for the formal definition.

*shrug* Isn't knowing something's name a lot like, "I've seen this word somewhere before, what is it?" I guess I do that too. If you mean something more than that, I think that only causes misunderstandings.

I'm sorry, Elysia, but computer science is not the only realm in which logic, objectivity, reason, and precision apply, and outside of that everything is just politics: "My opinion is my own and just as valid as yours" -- no, it isn't. It is WRONG. And being told you are wrong does not constitute a flamewar. Being told you are an idiot might, but I did not say that. ;)

Quote:

---

Originally Posted by Elysia

Casual definition is basically what I mean as knowing what something is and being able to describe it in your own words. This is absolutely critical. without it, you won't understand what something does.

---

Well I'm glad we can acknowledge this finally! Is that your way of saying, "Okay, I was wrong!"?:p

Quote:

---

Formal definition is what I mean by knowing the exact way something is defined, written down some place or some where. Like how a set is described in a mathematics book. This is typically less important, however, since you will be able to use and understand something with its casual definition often without the need for the formal definition.

---

The only way you could have exactly two distinct, discrete definitions -- a) "formal" and b) "casual" -- for all, most, or even many words would be if you just plain made them up as we go along, Elysia, and then pretended that they already existed as such. I do agree there are more concise and less concise, more in-depth definitions for anything, and for many things, within a specific technical context, there may be such thing as a "complete" or total definition, ie, one to which no more (relevant) information can be added (perhaps your earlier "formal definition" of list is such). I say, "within a specific technical context" (which would need to be defined), because eg, for the purpose of mathematics, the decimal numbers 1-1000 might have such a complete technical definition that mathematicians could all agree upon, but in a general purpose dictionary (if dictionaries included the numbers 1-1000), you might have a definition which is casual, but includes information not part of the supposedly complete formal technical information, such as, "666: in Judeo-Christian mythology, the number of the beast". That is not incorrect, but even if you knew the formal mathematical definition of 666, you might not know that, and hence, might be unable to understand the use of the label in some contexts.*

So these different definitions reflect the depth of knowledge of the one who uses them and the context in which they are used. Eg, if you were a member of some primitive tribe who'd never seen modern civilization but knew a few things about it, a very casual definition of "airplane" which would permit you to converse with your other tribes people about the "gleaming machines which fly and carry people" might not be sufficient to make use of such a machine, or to pretend to be a pilot on an online forum for aircraft enthusiasts.

The point is, a word/label/name alone is not any form of definition. Names for things can occur outside the context of a computer program, in which case they are "declared" without a type or any other information. Such a thing alone is what a name is, and it is not sufficient to impart meaning. If it were, we would not need to learn other (human) languages -- they would be immediately comprehensible just by hearing the words.

So what is it that is missing from the word or name which makes the difference between incomprehensibility/meaninglessness (again: odradek?) and being able to make use of a word to communicate information in conversation?

A DEFINITION.

You can pretend that all you really need is the name, Elysia, the same way newbies here can pretend they are right when they are wrong, even to the extent of wasting time with elaborate explanations of how what they really mean is such and such and why such and such a conception (which will never work) really will or should work if blah blah blah. Or you could just admit you are wrong because:

1) The word is not the thing.
2) The word does not define.
3) The definition is the meaning of the word.
4) A word without a definition is meaningless.

* 42 might be a better example, since I am not sure that the number of the beast, 666, is actually the same as "six hundred and sixty-six".

Quote:

---

Originally Posted by MK27

I'm sorry, Elysia, but computer science is not the only realm in which logic, objectivity, reason, and precision apply, and outside of that everything is just politics: "My opinion is my own and just as valid as yours" -- no, it isn't. It is WRONG. And being told you are wrong does not constitute a flamewar. Being told you are an idiot might, but I did not say that. ;)

Well I'm glad we can acknowledge this finally! Is that your way of saying, "Okay, I was wrong!"?:p

---

I am wrong in many things. But you don't need to use some roundabout way of saying that.
A simple, "no, that's not right," or "that is incorrect," is sufficient. Take a look at your post again. Then compare it to those sentences.

Quote:

---

You can pretend that all you really need is the name, Elysia, the same way newbies here can pretend they are right when they are wrong, even to the extent of wasting time with elaborate explanations of how what they really mean is such and such and why such and such a conception (which will never work) really will or should work if blah blah blah. Or you could just admit you are wrong because:

---

Here is where you are wrong. I never said a name is enough. Really, this is more of a communication miss.
To use what I said above, a casual definition is absolutely necessary. A name alone is never enough.
But a formal definition is not as useful as a name.

Quote:

---

Originally Posted by Elysia

I am wrong in many things. But you don't need to use some roundabout way of saying that.
A simple, "no, that's not right," or "that is incorrect," is sufficient. Take a look at your post again. Then compare it to those sentences.

---

I do not believe you are too dumb to understand that when someone explicitly contradicts you, they are, logically, saying you are wrong:

Quote:

---

Originally Posted by mk27 #20

I'm going to have to side with whiteflags about the relationship between definition and name.

---

Quote:

---

Originally Posted by mk27 #23

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.

---

etc. But I'll remember to try, "YOU ARE WRONG ELYSIA" in the future, if it means we can stop beating around the bush at that point. ;)

Quote:

---

Originally Posted by Elysia

Here is where you are wrong. I never said a name is enough. Really, this is more of a communication miss.

---

Is this your way of now saying, "I was never wrong, I just did not mean what I literally said."?

Quote:

---

Originally Posted by Elysia

post #10: Knowing the name of something (important) is not the same as knowing the definition of something (not so important). Separate those two concepts.

---

And it just does not end:

Quote:

---

Originally Posted by Elysia

post #34: A name alone is never enough.
But a formal definition is not as useful as a name.

---

No, you are still wrong. A definition, formal or otherwise, is what makes a word useful, because a word without a definition does not have a use. And the more formal or in-depth a definition is, the more useful it is.

I don't see you letting other people get away with bull........, and I respect you for that. So I realize I'm being a bit zealous, but I think it is important to refrain from introducing false dichotomies (and paving over real ones) by excusing sloppy language with sloppy thinking.

Quote:

---

Originally Posted by Elysia #27

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.

---

Does that mean, "I know I did not say it correctly, but that is okay, because what I meant is something different and you should understand that?" How about "I know I did not say it correctly. It would be foolish to believe knowing the name of something is more important than knowing the definition of what it is"? Without resorting to pop-up impromptu constructs like "formal" and "casual" definition. As if you could cover up being wrong by being even more wrong.

I think you are still in school. If you are, it might be useful for you to take a 200 or 300 level language or philosophy (or even: philosophy of language) class where you have to write essays (like, with a thesis, footnotes, titles with a colon in them, etc) on non-fiction material. Semiotics, lit-crit, that kind of thing. Wittgenstein or something. You know, totally subjective liberal arts crap that's otherwise beneath you ;) Honestly. $0.02

Quote:

---

Originally Posted by MK27

No, you are still wrong. A definition, formal or otherwise, is what makes a word useful, because a word without a definition does not have a use. And the more formal or in-depth a definition is, the more useful it is.

---

Grrr. I did not and I am not saying a definition is useless, formal or not.
I am saying that you most likely do not need to know the formal definition. Knowing the casual definition is a must.
I am wrong, then so be it. I will accept that. But I will not accept you accusing me of being wrong on something I have never mentioned or intended.
Apparently how I chose to write it has gotten some people (*cough* *cough*) to misunderstand my intent. That is a common occurrence, and I will happily admit that it may been poorly written.

Quote:

---

Does that mean, "I know I did not say it correctly, but that is okay, because what I meant is something different and you should understand that?" How about "I know I did not say it correctly. It would be foolish to believe knowing the name of something is more important than knowing the definition of what it is"? Without resorting to pop-up impromptu constructs like "formal" and "casual" definition. As if you could cover up being wrong by being even more wrong.

---

It means what I am thinking. I am distinguishing how I would describe something to how it would be written (in, say, a course book).
Casual definition = how I would explain it to others with words or by writing on a forum.
Formal definition = how it would be written in a college text book.

Quote:

---

Originally Posted by MK27

I do not believe you are too dumb to understand that when someone explicitly contradicts you, they are, logically, saying you are wrong:

---

A statement can be true or false. if it's false it can be said that it's wrong. But a person, however, cannot be neither false nor wrong. (unless by false you mean some type of human-like clone and by wrong you mean defective in some way)