Beginner Needs A Path To Guru

[deech]

Hi all,
I am a C/C++ beginner. I have a strong background in computer science
and object-oriented programming (my degree was taught primarily in
Java and I've used Smalltalk professionally). For a while now I've
been out of the mainstream programming world pursuing functional
programming languages (initially Lisp, now mostly Haskell and Ocaml),
but I want to get back in.

Can anyone suggest a study path for someone with a strong conceptual
base, but lacking in actual coding experience?

Thanks ...
-deech

 

[Victor Bazarov]

[..]
Can anyone suggest a study path for someone with a strong conceptual
base, but lacking in actual coding experience?

First off, don't set the goal to become a guru. It is rather hard for
you to know you've achieved it. Rather set the goal to be good at what
you do. Every day.

Second, for coding experience you need to be coding. Join a project.
Better if it's close in size to the ones you want to work on when
earning your living. There are open source projects available. But
don't expect anybody to babysit you, either.

Third, learn to switch between work and play. And I don't mean computer
games when I say "play". You need to learn to let coding stay at work,
and want to come back to it. Don't make it your life, it's only a way
to provide the means for normal existence.

So, to summarize, the study path is, set smart goals (specific,
measurable, attainable, relevant, time-bound), join a project so you can
actually practice in a real-world situation (not tinkering at home with
only yourself), and treat your activities as appropriate.

Good luck!

V

 

[none]

Hi all,
I am a C/C++ beginner. I have a strong background in computer science
and object-oriented programming (my degree was taught primarily in
Java and I've used Smalltalk professionally). For a while now I've
been out of the mainstream programming world pursuing functional
programming languages (initially Lisp, now mostly Haskell and Ocaml),
but I want to get back in.

Can anyone suggest a study path for someone with a strong conceptual
base, but lacking in actual coding experience?

Here is a suggestion that you won't see too often, but, in my opinion,
is the real way to master procedural languages like C, and subsequently
object-oriented languages like C++.

First, learn assembly. Assembly language is the ultimate procedural
(imperative) language. It is just a list of instructions that are
executed one after another to produce the desired result.

Write some programs in assembly. It isn't critical which assembly
language you choose, but x86 is probably the most documented, as well as
the most unnecessarily complex. If you can become reasonably proficient
in x86, you can handle any assembly language.

Assembly will teach you some very important fundamentals, if you really
practice it:
- What memory is, and how it is managed
- The separation of code and data
- What is going on "behind the scenes" with high-level languages
- How to optimize things
- That writing good comments is crucial to being able to maintain code
- That writing (and debugging) large programs in assembly is HARD

That last one is the crux. You'll start to notice patterns in assembly,
like, "Boy, I sure do use the combination of the TEST and JNZ
instructions a lot" ... and it might even make you think ... "It would
be nice if someone invented a high-level construct like an IF/ELSE
statement that neatly wrapped all of that up." And fairly quickly,
you'd see exactly where those C constructs came from. A few guys got
tired of doing things in assembly over and over, and invented C.

You'll then have no problem understanding C as a nearly 1-to-1
translation from assembly. That's exactly what it is. After managing
memory yourself in assembly, concepts like "malloc" and "free" in C will
be a piece of cake. And even more general things, like pointers (which
cause many a college freshman TONS of grief) will be trivial to
understand.

Making the leap from C to C++ is not much more difficult than the leap
from assembly to C. The same concept of invention applies: A few guys
got tired of writing the same types of things over and over in C (linked
lists, binary search algorithms, hash functions) and decided to package
it all up in a conceptually new language. Hence, C++ and the STL were
born.

I can't really give you a time frame for that progress, but I can say
that time spent at each "level" of understanding (assembly -> C -> C++)
is time well spent. Don't rush it.

Some will disagree with this approach, but they are simply wrong.
I've been using C since very shortly after it came into existince, and I
can tell you that by having learned it from the ground up -- as opposed
to starting with something very high-level like Java and working down to
assembly like most people do -- has put me far ahead of my peers. I'm
not gloating, it's just that I see my co-workers struggle every day with
things that seem obvious to me, because I have seen the man behind the
curtain, and they haven't.

 

[Juha Nieminen]

First, learn assembly.

There's no need to learn assembly. At most, you should study how the
CPU works and what kind of code a C++ compiler generates under the hood
(because that sometimes helps understanding why some solutions are much
better than others), but other than that there's really no need to
actually learn assembly.

You can also mostly skip learning C before C++. C is only going to
teach you very bad habits which will be very hard to get rid of when you
transition to C++. Old habits die hard, even if they are bad habits.

(OTOH it's good to know what C does and doesn't support, and how many
things are done in C. This is because many, many libraries out there are
written in C, and thus you should know what you can and cannot do with
them in C++.)

 

[none]

There's no need to learn assembly. At most, you should study how the
CPU works and what kind of code a C++ compiler generates under the hood

Good luck studying "how the CPU works" and "what kind of code a C++
compiler generates" without learning assembly. What kind of code does your
C++ compiler generate?

You can also mostly skip learning C before C++.

Sure, if you don't want to be good at C++. If you don't really care about
writing efficient programs, forget C and C++ alltogether and just stick
with Smalltalk. Or learn Java. Or BASIC.

C is only going to teach you very bad habits

No, that is not all that C is going to teach you.

Like I said, knowing the progression from assembly to C to C++ is very,
very valuable. If I had to choose between to new-hire candidates, and all
that I knew about them was that candidate A learned C++ from a book and
could talk all day long about virtual-abstract-inheritance-iterator-
templates, while candidate B had written assembly code for a Commodore 64,
I would hire candidate B every single time, without even asking him one
interview question about high-level OO and C++ concepts. Because I *KNOW*
that the guy who's fluent in assembly will have no problem learning any
procedural or OO language that I throw at him. I do not know that the
other candidate will be able to write decent code in any language.

 

[James Kanze]

There's no need to learn assembly. At most, you should study
how the CPU works and what kind of code a C++ compiler
generates under the hood (because that sometimes helps
understanding why some solutions are much better than others),
but other than that there's really no need to actually learn
assembly.

You don't really need to learn that either, at least not at the
beginning. The whole point of using C++ is that the language
abstracts you away from all this detail. (One of the best C
programmers I know didn't even know that computers used binary
arithmetic---in fact, he didn't know what binary arithmetic
was.)

You can also mostly skip learning C before C++. C is only
going to teach you very bad habits which will be very hard to
get rid of when you transition to C++. Old habits die hard,
even if they are bad habits.

(OTOH it's good to know what C does and doesn't support, and
how many things are done in C. This is because many, many
libraries out there are written in C, and thus you should know
what you can and cannot do with them in C++.)

With regards to the library, it's easy. You can do with them
exactly what their documentation defines. No more, no less.
You don't even need to know what language they're written in.