Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[zilpin]

See this rather exhaustive learning roadmap I wrote in another ĞLearning a coding languageğ thread.

[Moogie]

I'm no programmer yet. I dabbled in Actionscript for a couple of years and then just recently decided to jump in the deep end with C++.

I knew the merits of C# for beginners like myself, but I figured that even though I would struggle longer to learn C++, I'd develop a much better basis of knowledge that would help me when I did eventually switch to an easier language, like C#.

Was this smart, or stupid? Am I wasting my time thinking it's good practice to learn a lot of the "under the hood" stuff, before using a language that will effectively hide a lot of that for me?

Btw, I think I'm doing fairly well so far. I've been following this extensive set of tutorials and am currently up to Chapter 8.13. One great thing about those chapters, at least in the beginning, are the little quizzes at the bottom to test your knowledge and understanding of the material. Sadly they seem to stop appearing about halfway through, but I'm compensating by finding code challenges on other sites and testing myself that way.

[Nadaka]

Moogie, its a good way to do it. Most serious university CS programs start with c++ and then present the safer languages later (as well as data structures, assembly, deep understanding of hardware, math & logic, etc).

[alway]

I started with C++ myself; it really depends on what you feel like. I personally like teaching myself the really hard stuff first, since then if/when you take an actual programming course in the easy stuff, not only do you know how it works, but in some cases you even know various reasons as to why and how things can be done differently.

On the other hand, if you are having a hard time grasping the basics, it's probably best to start with a more simple language I guess. Although even that could be debatable.

[ILikePie]

zilpin's link reminded me of this.

Spoiler: A must-have in every code thread (click to show/hide)

[Moogie]

The only aspect I'm finding hard so far is knowing how to structure a program properly- how and when to use classes, references, pointers, etc; how to solve certain common problems the 'best' way, that sort of thing. It's one thing to learn the rules and syntax, but an entirely different beast to know how the code should be laid out to be both efficient and still readable.

[Nadaka]

Use classes mostly to model objects.

Pointers/references are a little harder to explain because there are so many different reasons and ways to use them. They are used to indirectly access data, allowing you to use the heap among other things.

Common problems and their solutions? Start by looking up data structures. Its typically taught as class number 3 in CS degrees and introduces you to organizing data in more complex and useful ways than simple arrays and objects along with a brief introduction to the concept of efficiency. Note that the c++ and every more advanced language already has all the common data structures implemented in libraries, but knowing how and why is a good place to start.

[Blank Expression]

Moogie, its a good way to do it. Most serious university CS programs start with c++ and then present the safer languages later (as well as data structures, assembly, deep understanding of hardware, math & logic, etc).

Hasn't been that way for years. The current trend in most places is to start with Java or something functional. C++ is, fortunately, reaching the point where it's used (correctly) as a special-case tool.

[ILikePie]

Aren't pointers just a way to pass by reference?

I thought I'd give Lisp a try this weekend, and I'd like to know which implementation to grab. Wikipedia says there are tens for both Common Lisp and Scheme, and my package manager finds about 30 packages when searching for Lisp or Scheme.
Never mind, I got some help from the nice folks at #lisp. sbcl it is.

[Moogie]

Aren't pointers just a way to pass by reference?

I think so, essentially. Pointer syntax confuses the heck out of me, though (the inconsistent use of asterisks depending on context).

[zilpin]

Aren't pointers just a way to pass by reference?

I think so, essentially. Pointer syntax confuses the heck out of me, though (the inconsistent use of asterisks depending on context).

More like "references are just safe pointers with abstraction overhead".

A pointer is an integer value which stores a memory address. That's it.
C/C++ let you have typed pointers, which conveniently know what data type they are pointing to.
C's grandparent language, BCPL, did not (nor real pointers, only integers, which it got creative with).

A reference is a unique identifier into a map of objects that the runtime library is tracking and managing for you, keeping track of how often and where it is used, re-using it's memory when nothing is using it any more.  When you get the value in a string object, for example, you go ask the runtime to look up the ID, then it goes to the correct place in memory, and it might increment a counter saying how many places the reference is being used, might copy the value to a new place, might do a lot of things, before returning the value (or, another reference).  And then some.

Core Difference:
Pointers are much faster, efficient, and dangerous than OO references, because...
1) References are managed by a pile of invisible overhead to access, and their allocation/deallocation are handled by the garbage collector.
2) Pointers are directly dereferenced by the CPU and their allocation/deallocation are handled by YOU.

They are also the primary point of angst for C programmers trying to find a difficult to isolate bug, not to mention buffer overrun/underrun security problems.

There is good a reason why automatic memory management & garbage collection has become so popular in modern applications, especially in the business community.
There is also a good reason that most graphics intensive games are still written in C/C++.



The problem I have with people starting with languages like Java and C# is how far removed they are from computing, due to the huge standard libraries that get students fixed on just one way of addressing problems.  In those languages you don't solve problems, you merely implement other peoples' solutions.  This is fine after you deeply understand the concepts, but undermines learning if you do not.

I usually suggest Python to start because it keeps it's concepts fairly base-level (even though it's a scripting language), and the libraries are largely third-party and have full source code to analyze.  It teaches core concepts, and teaches best practices, but leaves you to climb the mountain yourself.  Yet, still wears kid gloves.
But I only suggest it for introductory programming.


You can never achieve your potential if you don't grok how the CPU functions, or don't understand all the invisible OO magic that happens when you say:

Code: [Select]

foo.property = bar.method( parameter );

[Virex]

The problem I have with people starting with languages like Java and C# is how far removed they are from computing, due to the huge standard libraries that get students fixed on just one way of addressing problems.  In those languages you don't solve problems, you merely implement other peoples' solutions.  This is fine after you deeply understand the concepts, but undermines learning if you do not.

I usually suggest Python to start because it keeps it's concepts fairly base-level (even though it's a scripting language), and the libraries are largely third-party and have full source code to analyze.  It teaches core concepts, and teaches best practices, but leaves you to climb the mountain yourself.  Yet, still wears kid gloves.
But I only suggest it for introductory programming.

Interesting that you suggest starting with Python, because the power of python hinges strongly on list comprehension and functional programming, which are arguable very far removed from how a real computer work, and furthermore it's untyped, interpreted and garbage collected (I guess you could get further away with logical programming...) If someone's serious about learning how a real computer works he or she should learn to program in assembler first.

[Nadaka]

Starting in assembly is like jumping off a cliff while flapping your arms. C++ gives you enough rope to rappel down if you manage to avoid hanging yourself.

C++ really is one of the best place to start learning because it is close to metal with pointers and manual memory management, but can also introduce OO, libraries, etc.

[Virex]

Funny, I never had that feeling, but that may have been because it was part of a course on computer architecture...

[zilpin]

@ Virex
True, Python is removed from hardware.  But my primary complaint about Java/.NET is that they reinforce implementing someone else's solution instead of creating your own.  Python gives you access to high level concepts, but you still have to do your own problem solving.  Training wheels included.  Libraries exist, but are mostly external to the base language.
Learning the hardware comes later, it's why C is where it is on the list.
[tongue-in-cheek]
Of course, the best learning language of all is MMIX, but the course books are as yet incomplete.
[/tongue-in-cheek]


@ Nadaka
Hanging themselves is precisely what first-time programmers beginning on C++ often feel compelled towards.  It is good at convincing most people that programming is always miserable.

If assembly is like jumping off a cliff, then C++ is like Flugtag.
Sure, you have an impressive looking heavy complicated machine, the landing is softer, and the drop is shorter... but wouldn't you rather be flying?