Programming habits, standards, and learning.

[Snargleplax]

Good language choice depends on the paradigms of programming you're most comfortable in.

There's been a lot of discussion of C++, but I don't think anyone's mentioned that a lot of its complexity comes from being a multiparadigm language.  If you've got a good amount of exposure to not just imperative or OO programming but also things like functional programming, generic programming, metaprogramming, highly declarative style, etc.

If you grok this stuff and can spot when to usefully apply it, you can make C++ into a wonderful power tool for the right kind of job.  Of course, if you grok all that stuff, you're probably pretty good at picking up new programming languages generally.

Personally, I value C++ for its expressiveness and ability to create powerfully general solutions.  I find these unmatched in other languages of my experience, with Python running second due to its powerful and friendly functional programming support.  That suits me because I'm inclined to devote my obsession to such generality, but I think that many people just want to make a game and should avoid this route because they won't get enough out of it to justify the learning curve.

In practice, I find that memory management is not one of my more typical stumbling blocks; it used to be more the case before the advent of smart pointers, which reduce the problem to not much more complexity for 95% of cases than that of e.g. Java.

I'm trying to think of what I would consider my most common stumbling blocks.  Honestly, most of the time when I'm sitting there thrashing without making progress it's not really a language issue, but a visibility issue -- I just can't get the proper view on things to make obvious what's going on.  The best tonic I know for that is a strong willingness to take the time and build visualization in when you feel the need and can remotely justify it, because it pays for itself very quickly and keeps on paying.  Plus, you never know when cool new gameplay might come out of it.

Here is a truly excellent talk about immediacy in design that pertains to what I'm saying.

Okay, if I have to pick a C++ stumbling block though, I'll pick linking.  Always a PITA, one way or a damn nother.

To anyone who feels like they wish to use C++ but can't quite get over how screwed up it seems to be, I recommend reading Bjarne Stroustrup's The Design and Evolution of C++.  It's a charmingly personal, incredibly informative, and quite readable account of the language's early history.  Many design decisions are given detailed explanations that shed wonderful new light on C++ and the problems of language design in general.  I promise that reading this book will instill in you great new respect for Stroustrup, and at the very least grudging respect for the accomplishment that C++ represents.  Understanding why things have to be the way they are, what the compiler needs, etc. tends to make programming in C++ a lot easier because it feels less arbitrary (and hence easier to remember, too, since it's rooted in some principle).

[Krice]

but as soon as you decide to use anything else, you are doomed to C++'s data type hell.

Not per se. I think SDL is ok. What else do you need in a roguelike game?

[TheCreator]

Not per se. I think SDL is ok. What else do you need in a roguelike game?

An existence of one library is not an argument in favor of the whole language. There might be a thousand reasons why one would not want to use that library. In case of this particular library (SDL), for example, one might object at the fact that it is written in C. Using C code in your C++ code is a very good way to make the code more messy.

[kuniqs]

C++ is more cathedral-style language; great when you are 99% certain what you want to write. Add new ideas, code refactoring, bugs in multi-parametrized templates, multiple polymorphic inheritance with overloadings and the code gets undecidable.
Main problem of this language is the lack of standarization at compiler and library level. Amazing that mixing C and C++ is often easier than mixing C++ and C++. Standard library doesn't standarize sockets, windows, sound etc. only containers, which there are hordes around the net. There's also the problem of C++ claiming to be high level language, and C legacy you have to tend around the code.
The standard comitee is utterly insane - they couldn't bother to make lists, vectors standard types, support multithreading or include optional garbage collection to the language. Instead they approve existing libraries like boost as standard - check the lambda library if you think about learning C++. This was my first language, and I'm not sure if learning python/lisp first wouldn't be better.


Language wars aside, I advise learning:
- Scheme (very gentle introduction to functional language, much cleaner language than Common Lisp). Try DrRacket.
- Lua (fun little language, it's table-based OO rocks).
- C (the mother of all languages..  If you 'really' want to learn C++, learn C beforehand. Might cool you down a bit. Lua/Python were written with it, so it might come handy if you decide to learn them from the inside)
- C# (will be a cakewalk if you know VB.net)
- Python (since virtually everyone goes wild when hearing that word, why not go with the hype ?  I prefer Lua, but learning Python will certainly pay off for anybody).

Of course every one of them has major repulsivenesses - thousand and one Scheme distros, Lua is 'only' a C glue language, ancient imperative artifacts in C, windows dependancy of C# and rather not very serious Python community (Guido said we don't need it, so why question his decisions?).
Also try learning some dry Object Orientation theory (interfaces and stuff). Just don't practice OO with C++, with it's Encapsulation, Inheritance, Polymorphysm trinity.

[XLambda]

C++ is more cathedral-style language; great when you are 99% certain what you want to write. Add new ideas, code refactoring, bugs in multi-parametrized templates, multiple polymorphic inheritance with overloadings and the code gets undecidable.
Main problem of this language is the lack of standarization at compiler and library level. Amazing that mixing C and C++ is often easier than mixing C++ and C++. Standard library doesn't standarize sockets, windows, sound etc. only containers, which there are hordes around the net. There's also the problem of C++ claiming to be high level language, and C legacy you have to tend around the code.
The standard comitee is utterly insane - they couldn't bother to make lists, vectors standard types, support multithreading or include optional garbage collection to the language. Instead they approve existing libraries like boost as standard - check the lambda library if you think about learning C++. This was my first language, and I'm not sure if learning python/lisp first wouldn't be better.


Language wars aside, I advise learning:
- Scheme (very gentle introduction to functional language, much cleaner language than Common Lisp). Try DrRacket.
- Lua (fun little language, it's table-based OO rocks).
- C (the mother of all languages..  If you 'really' want to learn C++, learn C beforehand. Might cool you down a bit. Lua/Python were written with it, so it might come handy if you decide to learn them from the inside)
- C# (will be a cakewalk if you know VB.net)
- Python (since virtually everyone goes wild when hearing that word, why not go with the hype ?  I prefer Lua, but learning Python will certainly pay off for anybody).

Of course every one of them has major repulsivenesses - thousand and one Scheme distros, Lua is 'only' a C glue language, ancient imperative artifacts in C, windows dependancy of C# and rather not very serious Python community (Guido said we don't need it, so why question his decisions?).
Also try learning some dry Object Orientation theory (interfaces and stuff). Just don't practice OO with C++, with it's Encapsulation, Inheritance, Polymorphysm trinity.

Heh, nice choice of languages. I personally would add Haskell - IMO it's more of an academic thing than an industrially used language, but it's very cool and a tad more readable than scheme/cl. I learned functional programming with Haskell, and still use it for solving mathematical tasks.

[dscreamer]

The standard comitee is utterly insane - they couldn't bother to make lists, vectors standard types, support multithreading or include optional garbage collection to the language. Instead they approve existing libraries like boost as standard - check the lambda library if you think about learning C++.
...
Of course every one of them has major repulsivenesses - thousand and one Scheme distros, Lua is 'only' a C glue language, ancient imperative artifacts in C, windows dependancy of C#
...

Unless you're already invested in Windows Forms or other Win-specific things, the Mono framework actually makes crossplatform C# rather painless. Of course, C# (and every other language) still isn't perfect, but I do think it's a good choice to learn with.

[Krice]

In case of this particular library (SDL), for example, one might object at the fact that it is written in C. Using C code in your C++ code is a very good way to make the code more messy.

C library routines don't actually force you to code C, you can of course use C++ in your source code. Library routines are more like additional keywords and their impact on readability should be nonexistent. Besides when using SDL as graphics library it's often a good idea to create a higher level GUI class for that purpose rather than using SDL directly.

[kraflab]

SDL is old and decrepit.  It makes complete sense that it mucks up syntax if you try to use a c library in c++.  The paradigm is necessarily going to get wacked out.

[Krice]

It makes complete sense that it mucks up syntax if you try to use a c library in c++.

Wrong.

[kraflab]

It makes complete sense that it mucks up syntax if you try to use a c library in c++.

Wrong.

Look, c is terrible.  I hope we can all agree on that 

[Krice]

Look, c is terrible.  I hope we can all agree on that  

It's the way people program C that usually sucks, and yet worse they replicate it in C++ also. After all you can program a lot like C style in C++ if you want, because C++ doesn't force to use OOP (or force you to be a good programmer).

[TheCreator]

- C (the mother of all languages..  If you 'really' want to learn C++, learn C beforehand. Might cool you down a bit.

If you really want to learn C++, learn C++. C doesn't contain any single language feature that's not present in C++. But I think you actually meant learning procedural programming, didn't you? C++ is not Java, it does not enforce OOP in any way, so you can still program procedurally if you wish to.

C library routines don't actually force you to code C, you can of course use C++ in your source code. Library routines are more like additional keywords and their impact on readability should be nonexistent. Besides when using SDL as graphics library it's often a good idea to create a higher level GUI class for that purpose rather than using SDL directly.

Yes, you would need to waste your time to create an object-oriented wrapper for those medieval SDL routines. Which means that you need to thoroughly understand their own data type system, so that you always know whether you can convert from SDL's Sint32 to int. Or how to deal with the funny type SDL_bool.

It's not an impossible task, of course. You probably know how to do it, I know it too, but a novice programmer doesn't even know that he needs a wrapper. In Java this problem doesn't exist, because every library uses int or Integer and Java doesn't need to support legacy languages like C. That makes a huge difference.

[Krice]

Yes, you would need to waste your time to create an object-oriented wrapper for those medieval SDL routines.

GUI class can be more than just a wrapper.

Which means that you need to thoroughly understand their own data type system, so that you always know whether you can convert from SDL's Sint32 to int. Or how to deal with the funny type SDL_bool.

When you "hide" SDL in a GUI class you don't have to know anything about SDL. I think you haven't realized how things can be done. Check out Teemu's source code and its gui class. It's a simple example, but you might get ideas.

[MorleyDev]

Hmm, good habits?

Nowadays I advocate test-driven design. Testable, loosely coupled code that can easily be debugged and refactored? Yes please.

Also red green refactor. Always refactor. Keep the code as clean as possible, you'll regain that technical debt ten-fold when the time comes to optimise, change functionality or extend code. Refactoring is very good. And since your TDD has given you good test coverage, you get instant feedback if you accidentally broke something.

[tuturto]

Nowadays I advocate test-driven design. Testable, loosely coupled code that can easily be debugged and refactored? Yes please.

Composition of objects that can be arranged in new ways to produce new software, without having to first break apart huge amount of dependencies, I like it too.

My latests roguelike is being written using TDD and I have gotten much further than before (it's like 3rd or 4th try). I spend more time on writing new code than debugging old and fixing bugs, which is really important with limited amount of time I have in my disposal (granted, I spend time on writing tests, but my gut feeling is that it's still faster).