Having Trouble With Semantics

I just read this article which BigEd suggested for PinkFloydEffect, and it sums up the problem that I'm having with semantics and programming.

I have a list of about 20 different books that I'm using to help me learn C#. I rely mostly on Illustrated C# 2008, published by Apress, because the illustrations make it easier to 'visualize' what is happening.

Ocasionally, I'll refer to other books if I have trouble understanding my main read. The one thing they have in common, is that they lay out all the rules very clearly... but fail to explain WHY things are the way they are, or which is preferrable in a particular situation. I'm shown a bunch of mind-numbing facts and laws to memorize, without really getting a clear explanation of why I need to know these things, or when to apply them. It would be easier to commit all these rules to memory if I could understand why I need to know them, or when they are applicable.

Has anyone else had this problem, when learning to program, or am I just reading all the wrong books?

Yup, this seems to be something that comes with experience. It took me a while to really "get" polymorphism. Sure, I knew the keywords and how classes and interfaces worked, but I didn't really appreciate why anyone would need such a thing until I actually ran into a problem where the use of abstract interfaces *really* made my code better and more maintainable.

So, the good news is that, as long as you keep programming, you will eventually "get" all of this stuff at a deep level. The bad news is that you will likely have to discover it on your own.

There is a good chance that among those 20 books there is at least one that can suit the way you learn.

IMO, it's good to use 2 or 3 books on the same topic, as the different authors my have different views of the same thing, or may express in different ways, which can help you understand the concepts better.

But, starting with more books than that can be counterproductive - as your focus might spread too much (IMO).

As for the semantics, much of this is up to you - and that's the problem with understanding the essence of anything (in life): nobody can really do it for you, because, by the nature of things, it requires effort on your part. (Some book or person might make it significantly easier for you, though, but only you can walk over the threshold).
Some things you'll come to understand sooner, some things will you'll reveal later.
Some things require you to first understand some other things.
And this is all achieved through some sort of practical work, through the act of fighting to solve and understand a problem. (The words "practical work" and "problem" are used in a more general sense here.)

So, the first thing to do is to start.
Obviously, in order to write code, you need to learn the basic language rules, how the basic stuff works. Read, then try to understand, than read some more, and see if it fits in your theory. If not, see why not, learn from it, form a new theory, and test it again. Find examples on the web. Find more info. Ask questions on a forum.

Try to run the code snippets in your head. Compare what you expected with what actually happened. Learn from it.
And don't forget - a pen and a paper are your greatest tools, and powerful allays.
Scribble, draw, go crazy with the colors, diagrams, functions, tables, what-not, throw it to the trash, and do it again.

Learn how & where to find the relevant information, and learn to understand it. You can't have all the details in your head. The fundamental principles are what's important.
And never allow your self to get lost in the details, always keep the big picture in your mind's eye.

Practice, practice, practice.
Try to create this, then try to create that.
Be brave & try doing something that seems challenging to you.
Think of failures as of a chance to learn something from them.
And learn to use the the debugger (not that hard, believe me).

Take what you have learned, connect it whit similar concepts you know of, and abstract it into something more general, more fundamental, something that represents "what it's actually all about" (semantics == the meaning).

Simply, consider yourself to be an explorer of this field.

-----------------------------------------------------

OK. That was pretty general, abstract even, but so was the question.
But, I'd like to hear what is it that you have trouble to understand. Something concrete, one thing at a time; sometimes, all it takes is a nod in the right direction.
So, state the problem, and state what you think of it.
Say what is it that's not clear to you, and why.

As I've heard before, and agree with.

Don't just read a book. Read it once. Then read it again, and with the samples, TYPE IN THE CODE and RUN it. Even if they provide sample programs, do it yourself.

Run it. When it fails, figure out why, or just type it in, again! Meaning, erase what you did, first.

When it works, then move on to the next chapter of the book.

It doesn't help to read books, without DOING things. Learning HOW to debug properly is probably the most important facet of programming.

Quote:

---

Originally Posted by dglienna

Then read it again, and with the samples, TYPE IN THE CODE and RUN it.

---

This is the key for me. Justing looking at the code doesn't get it done - I need to type in the code to understand new concepts.

I agree that 'hands on' is essential to learning this stuff. There are some great books, but they can only do so much. I've read chapters, worked through examples, and memorized syntax, but was unable to really grasp the underlying concept until trying to write my own code from the ground up. Most of my revelations have come during a morning cup of coffee, after an evening of hammering and wrestling with a piece of code that wouldn't work. It's those hard fought battles that I tend to learn the most from.

I guess that classifies me as a 'cargo cult' programmer, but I think it's like Ed said_ learn the syntax, keep programming, and the deeper levels of insight will come later.

Also, being able to draw on the knowledge of others has been an invaluable resource. TheGreatCthulhu is right that sometimes it only takes a nod in the right direction.

Quote:

---

Originally Posted by mbegley

I guess that classifies me as a 'cargo cult' programmer [...]

---

Not necessarily , because of:

Quote:

---

Originally Posted by mbegley

Most of my revelations have come during a morning cup of coffee, after an evening of hammering and wrestling with a piece of code that wouldn't work. It's those hard fought battles that I tend to learn the most from.

---

Being a cargo-cultist programmer is about having a certain attitude: "Let me see... I'll change the title and the label text... OK. OMG? Why it wont compile? Oh, you can't have quotes within quotes!? Doesn't make sense to me, but what can you do. And now for the super-cool video filtering functionality I had in mind... Ehm, there's no predefined video player... I'll just go to a forum, explain what I need and someone's gonna do it - it's probably gonna take two minutes their time... [later on] Why won't this guy just stop bugging me with "learn this, learn that"? Just post the code, man!"

Now, that's the intermediate-to-advanced cargo cultist. There are also novice/beginner cargo cultists - they post their homework text and expect the solution in the next post. Then they follow up with a typical: "What? 25 views and still no answer!? Move it, people!".


BTW, I found some images related to the origin of the term:
http://blog.bhargreaves.com/wp-conte...cargo-cult.jpghttp://www.damninteresting.net/content/FrumParade.jpg

Haha, those pics are great. I hadn't heard of a 'cargo cultist' before reading the blog article. Even afterwards, I thought it may be, more or less, an exaggeration just to make a point, but the pictures really drive home the meaning. I'm sure I'll remember that term now. :D