views:

274

answers:

4

I'm looking for a guide to the basic concepts of programming, that are explained in a good amount of depth.

By this I mean something that describes what:

  • Object oriented programming is...
  • What compilers are, how they work, etc..
  • General descriptions of how programs work on a deeper level - such as, say, everything is in binary. But we write programming code. How is one converted to the other?
  • What are the standard differences between Unix-based and Windows operating system programs? (Apologies if this sounds ignorant - I've never used a mac in my life, and have only used Ubuntu for about a month a while back, not doing anything programming related - hopefully you can infer the meaning of my question)
  • Where would I research things like, say, I know about - where would I learn about other things such as this, what they contain, how to use them? This is a library? Namespace? What? What does that mean?
  • What can a text editor do for me? (Emacs? Why would I use hat over the text editor inside of visual studio?)

etc. etc...

Just the real simple basics of how programming works in general terms - not specific syntax's of specific languages, just broad things like "What is a compiler".

I want a book like this, beginning from a beginners level. Lets say, I have a generic idea of how computers work, but really don't understand any programming concepts such as these really basic ones. (I do in reality, but I really want to get back to basics).

I don't necessarily mean that I need each of those questions answered within the book, but it should give you an idea of what it is I'm asking for. If it doesn't exist, have yo any other ideas? Doesn't have to be a book - can be a video, tutorial, website, blog post, anything - though I'd prefer a book.

As a final note: If you feel like giving an answer to any of those questions in Laymen's terms, I think I could reaffirm my knowledge (as a novice), and also create a good thread for any other newbies to find that might help a -lot-.

/* Note: If such a book doesn't exist for a generic idea of what programming is all about, then something specific to C++ would be great. Ideas behind the concepts and ways things work are important though, I don't just want -another- book teaching me how to code "Hello world"

Feel very free to edit this post, if i'm being unclear - i'm not very good at expressing myself clearly in English.*/

+6  A: 

There is a great free eBook called Foundations of Programming by Karl Seguin, which you can download here.

hmemcpy
+5  A: 

Wikipedia will probably have good answers to the objective parts of your question(s), and will give you some idea of where there is controversy about the subjective parts.

And here are some "layman's terms" answers to the specific questions, like you also asked for, to get you started:

What is Object oriented programming

It is a way of thinking about programming where you imagine it as many separate things called objects that communicate with each other. Each object has a set of messages that it is able to receive and understand, and it can store information (numbers, text, other objects) in named fields.

The shape of an object is called the class of the object, so two objects with the same shape are said to be "of the same class".

Usually there is a way to make a new class that extends an existing one (e.g. adding new messages it can receive), such that an object of the new class can be treated exactly as if it was of the old class. This is called polymorphism (a word that is used in a slightly different way than in other programming contexts).

What compilers are, how they work, etc.

In the simplest cases, a compiler reads one file (the source) and writes another (the binary). It can be made more complex than this, but that is a very simplified version of what is going on.

The purpose of a compiler is to convert a program from a form that is easy for a person to edit into a form that is easy for a machine to run.

The source file is plain text that can be edited easily. The text has to conform to a strict language definition. The compiler just follows a lot of rules for converting chunks of the source code into the equivalent instructions for a machine to follow. Those instructions are packed together in numeric code in a way that would make them hard to edit directly, but easier for the machine to run.

Some complications:

  • there may be many separate source files that are combined together
  • there may be intermediate output files (sometimes called object files, nothing to do with object-oriented programming) which are then joined together by a linker to produce the executable
  • the output may be machine code that a CPU understands, or it may be some other format that needs further translation by a virtual machine, such as Java bytecode or Microsoft IL.
  • the compiler may be able to produce a library, which is not a complete program (see below)

What are the standard differences between Unix-based and Windows operating system programs?

The differences are not particularly fundamental any more. Both operating systems have influenced each other and have many broad similarities; they differ only in lots of small details. For example, file paths on windows have backslashes, on Unix they have forward slashes, and it's the same with their programming environments.

For example, both have a function that lets you open a file so you can read it from the hard drive, but they give the function a different name, and the parameters are specified in a different order. And yet it is pretty easy to write a "wrapper" function that emulates the other system's way of doing it. On Windows, you can use the Cygwin library to compile Unix programs. On Linux you can use Wine to make Windows code work. These are just "layers" of wrapper functions.

This is a library? Namespace? What? What does that mean?

A library is a chunk of code that is not a complete program by itself, but is intended to be used in the construction of a complete program.

The term namespace appears in situations where the programmer is able to invent their own names for things. Those names have to be unique; you can't use the same name to refer to two different things. But how unique do they need to be? If you and I write different programs, we can both use the name "customer" for our own purposes, without a problem. It isn't necessary for all the programmers in the world to cooperate and make sure they don't use the same names. This is because they are working in separate namespaces. The names we choose only need to be unique within the namespace they exist in.

Namespaces can often be treated as a hierarchy. An example is a computer's file system. Each directory (or folder) is a namespace. The files directly inside it have to have unique names, but only unique to that directory. Every file on a hard drive can also be uniquely identified across the drive by using the "path" through the hierarchy, formed by adding together the names of all the directories that contain the file.

It's the same in many programming languages, where you can use a path to refer to a unique item in the "global namespace" using a kind of path to it. Each language uses a different character to separate the path elements (just as operating systems use a different character, forward or backward slash, as the path separator), but the dot character . seems a popular choice. In C++ there are at least three different ways to do it, depending on the context:

namespaceA::namespaceB::classC::memberD

variableA.memberB.memberC

pointerA->pointerB->pointerC

What can a text editor do for me?

It depends. A truly plain text editor cannot do much besides edit text. But the editors used by programmers can usually help more by:

  • syntax highlighting, colouring parts of the code to indicate what they mean
  • refactoring, commands that make large-scale changes to the code, e.g. "rename this class and automatically fix all the other places that use the old name"
  • starting the program running and let you "pause" it, examine the values of variables, step through it one line at a time to see where it goes wrong (debugging)

When there are enough such features, it ceases to be a mere text editor and becomes an IDE.

Daniel Earwicker
I hate it when people give an overly simplistic description of OOP such as the one you've given. It's just completely wrong.
hasen j
I think I did a pretty good job of capturing what little could be captured in fifty words or so, but I'd be interested to see your attempt. Why not post an answer and see how short you can write it? Incidentally, to say my answer is "completely wrong" is pure hyperbole. There's nothing wrong in it at all; it's just short and leaves a lot of stuff out.
Daniel Earwicker
I didn't say your whole post is wrong. The part about OOP is wrong because that's not what OOP is all about. Sure, classes, objects, etc. strictly speaking, that's not wrong, but when someone asks "What is OOP" and you say "it's thinking about your program as a bunch of objects", I consider that to be wrong.This kind of answer is all over the web, and more and more people think that's what OOP is. It misses the essence and goals of OOP, and leaves a very wrong impression; that of a pointless buzzword.
hasen j
Then my challenge still stands - your description of OOP in your answer is a cop out. Cohesion and coupling are issues that apply as much to structured or procedural programming, not specific to OOP at all. Let's see a brief description of what is specific to OOP from you! :)
Daniel Earwicker
For other readers, hasen j’s attempt to explain object-oriented programming is [below](#answer-903351) (or above, if it’s been voted up since then). And I’m with Daniel — I don’t quite see how his description helps understand OOP.
Paul D. Waite
A: 

Another good book is Code Complete 2 from Microsoft Press. Highly recommended.

anthon
code complete is probably not a book for a novice who havent begun programing. It is for the apprentice programmer who have learnt some basic concepts, but need further guidance.
Chii
+1  A: 

That's probably the wrong approach to teaching programming. Dare I say, it's The One True Wrong Approach.

At first, you say:

I'm looking for a guide to the basic concepts of programming, that are explained in a good amount of depth.

Well, if you really want to go in depth, then your audience better know the basics of these concepts; they should have written some code.

But then you say:

Just the real simple basics of how programming works in general terms

Well, do you want the basics or the depths? OK, maybe I'm being a bit picky.

What I understand is that you want to use these concepts as an intro to programming to an audience of non-programmers who are trying to learn programming. Am I not correct?

Object oriented programming is...

This is one of the tough things to define. One reason I suppose is that different people define it differently. It mostly boils down to experience. Those who write real applications, and care about the code they write, will have a completely different idea about OOP than those who studied OOP from a "dummies" book and then went on to write procedural code in Java.

I mean, some people think they're writing OO code simply because they have "classes".

One can't really understand what oop is until he has written a substantial amount of procedural code (e.g. in C).

OOP are a set of ideas about ways of achieving high cohesion and low coupling.

I think it's a misfortune that they have the term "object" in there.

Objects in OO code don't correspond to real-world objects about 98% of the time; they usually correspond to some abstract ideas about the program flow. For instance, "events" in a gui application are objects. Events are representations of things like key-presses, mouse movement/clicking, button pressing, getting/losing focus, clock ticks, etc.

It's really hard to explain what cohesion and coupling is to someone with no programming experience.

Cohesion means that a piece of code should be responsible for a single (and hopefully simple) task, and that it should do it well. That's a good thing and we should try to increase it.

Coupling is when different parts of code are, well, intertwined together in such a way that it's really hard to change that code. Because all parts are dependent on each other, changing one part will break the whole structure. Coupling is a bad thing and should be minimized.

When you have a large amount of code that's very entangled together, it's "spaghetti" code. low cohesion and high coupling: it's trying to do everything at the same time; and it's grown so large that it's not manageable anymore.

What compilers are, how they work, etc..

Well, you could write about that, but there's no point going in depth about it. Better to just give a simplistic idea such as "converts text into machine code", then teach them just the basics of how to use it to get some code to compile.

They can learn the more "in-depth" stuff later.

General descriptions of how programs work on a deeper level - such as, say, everything is in binary. But we write programming code. How is one converted to the other?

Well, again, you really can't go deep (in concepts) before touching the surface first (writing atleast some small programs).

You have to learn assembly, learn about how the CPU works, etc. When you have all the information, you'll be able to put all the pieces together and understand how the whole stack works.

What can a text editor do for me? (Emacs? Why would I use hat over the text editor inside of visual studio?)

They're just different programs that do the same thing in the end. For starters, just pick one and learn it.

Really, for a beginner there's no difference; they're not gonna write that much text anyways.

The only feature they need is auto-indentation and a mono-space font.

Where would I research things like, say, I know about - where would I learn about other things such as this, what they contain, how to use them? This is a library? Namespace? What? What does that mean?

Well, this comes from experience. As you learn more, you'll just know where to look for more information.

For example, if you want to know what namespaces are, it's probably because you've encountered the term somewhere; maybe in a C++ tutorial? or maybe in that sample C++ program that has "using namespace std;". See, you already know where to look: google C++ namespaces.


If you're asking these because you're a beginner yourself. Well then, you can always google for answers, or just ask stackoverflow.

hasen j