Quote:Original post by Anonymous Poster
Other languages all contain subsets of the concepts you can learn in C++.

Um... no.

C++ doesn't have tuples. Or reflection (though reflection libraries do exist, but they're awkward - you have to derive all your types from one of theirs, for instance - and it's not language native). Or introspection. It has no package functionality, just namespaces. Its approximation of generics - templates - result in not insignificant bloat if instantiated with multiple types.

This is not to say that it is not powerful, just to remind you to watch the hyperbole. Just because you don't know of features that C++ doesn't have but other languages do doesn't mean they don't exist.

Quote:The other bottom line is your bottom line. The lower level you go the more valuable you are. If you don't understand the lower levels of how things work, you are very disposable. You'll always be behind the curve and just keep slipping further and further into obsolecense.

Debatable. The current trend appears to be imbuing both the operating environment and the compilation process with more information and/or intelligence, allowing them to make a variety of automatic optimizations that yield code translated from very high levels which rivals hand-crafted code in performance. It can be argued that the demand for truly low-level developers is shrinking, perhaps soon to be constrained solely to operating systems and developer tools. That is a very small subset of all written code, most of which resides at a much higher application level.

Quote:Remember: any code monkey can use blackboxes. It takes a real programmer to write those blackboxes.

Debatable. Some "code monkeys" can write black boxes, but can never pull together boxes from disparate vendors to create a usable product - witness the plethora of "my own engine" projects, but the dearth of "my completed game" announcements.

But all this is completely beside the point. For a beginner, it is more important to provide an environment in which relatively rapid results can be obtained and good programming practice can be learned. C++ is not that environment, IMO.

Quote:Original post by Anonymous Poster
In response to: if you can code in C++, you can code in anything - "That ain't true."

You must be new because it exactly is. C++ allows you to do anything.

That doesn't mean knowing C++ allows you to code in anything.
C++ is Turing-complete, yes, so you can in principle do anything in C++.

But some languages have *nothing* in common with C++, and you might even find that knowing C++ is a big hindrance when learning those languages.

Be careful calling other people "new" or correcting them when what you're saying just isn't true. :P

Check out Lisp, Prolog or ML, just to begin with. Those have absolutely nothing in common with C++

Quote:Original post by Anonymous Poster
In response to: if you can code in C++, you can code in anything - "That ain't true."

You must be new because it exactly is. C++ allows you to do anything. Other languages all contain subsets of the concepts you can learn in C++.

A truly absurd generalization, which is ignorant of differing programming paradigms and language-specific idiom. Go try writing something in Lisp and tell me about how a C++ background enabled you to just pick it up instantly.

Quote:"Nowadays, it does not matter anymore what Language you use . The hardware card takes much of the load, and the DirectX or OpenGL calls are basically the same- whatever language one uses."

More misguidedness from the "I just got here, where's my GHZ?!" camp.

Believe it or not there are still systems which do not run at 3.6Ghz or have GeForce FX Ultras or support OpenGL/DirectX.

Believe me, I know it. I develop for mobile (i.e. cell phones). They most assuredly do not offer processing power that comes anywhere near anything available on a desktop. Do you know what I use on them? J2ME. Yeah. As in Java 2, Mobile Edition. It exists and is a very popular platform, with good reason.

Quote:And, believe it or not, you do actually have to know the concepts which those APIs wrap into nice blackboxes before you can really make them do things.

Er no, you really, really don't. That's what the APIs are for, you know. It has been decades since computer time was more valuable than human thinking time. Your time as a programmer is much better spent getting things to work than trying to "really do things" (whatever you think that means?) right from the get-go. And it axiomatically takes less time to do so when you use tools which make it easier to do so.

Quote:What good is an integrate button if you have no clue what it's good for much less when to use it? If you don't understand the inner workings of the hardware you're going to waste a lot of time trying to get DirectDraw to rotate things and be entirely confused as to why you can't.

I can't even make sense of that. If you don't know what you can or can't do with an API, you look up its documentation. If it doesn't provide a particular bit of functionality, the reason is "that's not part of the API's design philosophy".

Quote:John Carmack would not be where he is today if he did not write Wolfenstein 3D. Anybody who's paying attention realizes what a tight logical progression through the concepts of 3D all his games are.

Define "concepts of 3D".

Also, consider how much more processing power desktops have today than they did when Wolfenstein 3D was released. Now consider the probability of anyone in For Beginners successfully completing anything as "good" as W3D, even on today's hardware with tools that take advantage of the available power.

Quote:He didn't miss a step and you simply can't skip one. Otherwise, you'll always be dependent on someone else.

Good heavens. Lord forbid any of us should be dependant on anyone else. I suppose you would like us to code up our own web browsers from the ground up, too, just in order to have the priviledge of replying to you.

As for the rest - Oluseyi said it better than I could.

Quote:
Whoa. I wasn't expecting this big of a reception. Anyway, to hell with odds - I'll try to learn as I go, if possible, and maybe write tic-tac-toe while I manage whatever I can with the FPS. If I can't, I'll just stumble back here and just learn. How does that sound?

Not recommended. Sorry to burst your bubble, but if you have no programming experience, you will not succeed in making an FPS. It's far too complex for a beginner. Instead of learning as you make progress in the FPS, you will make bad habits which will take considerable time to mend. As many others have already said, start with simpler, less complex games so that you can develop good habits. Make a maze game, or maybe a '1942' clone. But not an FPS. While working on simpler projects, perfect the design for your FPS in your spare time, that way when you do have the skills to make it, the design will be finished and work can begin much more quickly.

"Good heavens. Lord forbid any of us should be dependant on anyone else. I suppose you would like us to code up our own web browsers from the ground up, too, just in order to have the priviledge of replying to you."

Reduction to absurdity.

You should seek to go further and further down. I don't see a need or a point to starting at the absolute top; BASIC. If go into computer science at a university you start with logic gates then go to assembly before starting any higher languages like C++ and LISP. You have to understand the low levels before you can fully master the high levels.

And you shouldn't rely on APIs because eventually you may want to do something that they can't do. So while you use them, you should be working to understand them at more than the API level.

"I can't even make sense of that. If you don't know what you can or can't do with an API, you look up its documentation. If it doesn't provide a particular bit of functionality, the reason is "that's not part of the API's design philosophy"."

What's not to make sense? If you don't understand 3D concepts how do you intend to figure out which API function call you need? And if you know of a function call but don't know the 3D concept behind it, how are you to know when to use it?

If you don't understand matrices, good luck figuring how to make DirectX or OpenGL do anything interesting. If you don't know about matrices, good luck finding the API function calls in the docs. Unless you intend to read the entire set of docs and learn 3D concepts from them at the same time. Hint: the docs don't cover 3D concepts.

You need to know 3D concepts before the API or it's docs are of any use.

Like I said, who cares if you know about the integrate button if you have no idea what it does or what it's good for.

http://www.icarusindie.com/wiki/index.php/MTE482_Discussion_1

^^ if you still don't get (what I think is a clear analogy), that page elaborates on it.

Quote:Original post by Anonymous Poster
If go into computer science at a university you start with logic gates then go to assembly before starting any higher languages like C++ and LISP. You have to understand the low levels before you can fully master the high levels.

Rubbish.

Computer Science is Mathematics, Kalvin, not Electrical Engineering. Discrete Math and Set Theory are far more central than logic gates ever are. In fact, constructs like logic gates are only tangentially referenced in both the basic and Advanced Computer Organization classes, which are usually paired with some form of assembly language. Yep, assembly language is taught after higher-level languages including Java, C and C++.

Many Computer Science departments now use Java as their central language, from the first programming class to the last, with the exception of special classes. This is the case, for instance, at Stony Brook University (SUNY). At UNC Greensboro, on the other hand, C++ is the central language.

Quote:And you shouldn't rely on APIs because eventually you may want to do something that they can't do. So while you use them, you should be working to understand them at more than the API level.

"Laziness is the foundation of efficiency," according to Larry Wall. Whenever you can locate an existing, reasonably well-supported library that provides the functionality you seek, it is better to integrate it rather than write your own. Why? Because of the overhead of design, implementation, testing, refactoring and generally producing quality code. Only if you can't find any library, or if the libraries aren't sufficiently performant, do you implement your own.

Quote:What's not to make sense? If you don't understand 3D concepts how do you intend to figure out which API function call you need? And if you know of a function call but don't know the 3D concept behind it, how are you to know when to use it?

Read the documentation. The Direct3D documentation, for instance, includes backgrounder material on basic 3D concepts. I agree with you that at least a basic grasp of the principles at play is important, but I disagree that you can not or should not use APIs without fully comprehending the underlying concepts.

Fact is, for instance, that a user of Direct3D does not need to really "get" matrices. All he needs to know is that Direct3D uses them to represent transformations, and how to build the appropriate transform - which is where the variety of D3DX functions come in useful. This clearly undermines your argument better than any philosophical pontification on our parts.

"C++ is, as was stated above, Turing complete—any computation that can be carried out on a Turing machine, and therefore every computation that can be carried out on a computer, can be implemented in C++. However, that does not distinguish it from most programming languages."

Who brought up "Turing complete?"

What makes you think that "turing complete" would be a consideration between choosing BASIC and C++?

Can you seriously not see the striking differences between the two languages in their capabilites?

No where did I attempt to distinguish C++ based on it's ability to compute things.

C++ is far far superior to BASIC in it's capabilities which extend far past being turing complete as anybody who's used more than a single language knows.