Temple of The Roguelike Forums
Development => Programming => Topic started by: Shaggy on October 18, 2012, 09:57:52 AM
-
I started programming when I was very young - 12 or 13 iirc - thanks to my dad. He showed me the fundamentals of Visual Basic 6, and gave me a few books to read. Fast forward and I took a single programming class in highschool. Other than that, I have no formal programming training.
Ive tried learning many other languages (C#, C++, Ruby, Python), but I always end up coming back to Visual Basic. Although Ive switched to .Net, I still feel like this is a 'beginners' language. I feel like it has somehow hindered my ability to branch out and to learn new languages or even styles of coding.
What can you advise for me to (in a way) re-learn to program, and how to program more efficiently and to a higher standard?
-
Ive tried learning many other languages (C#, C++, Ruby, Python), but I always end up coming back to Visual Basic.
The essentials of programming are not tied in any particular language, they are generic concepts. Languages are a way to express those concepts in different ways. The way people try to learn a language is often wrong, because they pay too much attention to syntax and trying to learn everything in that language. I think the proper way is just try to write programs and then see what is needed. Even C++ is thought as "low" level language, I almost never use templates (except STL ones). You don't need everything, just the stuff that makes program work.
-
In terms of programming more efficiently and "to a higher standard," I think you shouldn't really worry about such things. Just keep programming and such things will follow naturally. As Krice said, just choose another language and start using it. Don't worry about using the "correct" paradigms and whatnot. Most people will tell you to just stick with whatever language you know best, but on the contrary I would say every language you learn to use makes you a better programmer in general.
-
I would say every language you learn to use makes you a better programmer in general.
Especially if you try programming languages which are based on something completely different (say, functional ones).
-
Try out FreeBasic - the syntax will be familiar, and ultimately it's as good as C++ for making roguelikes.
-
VB.Net is good language. Worst part of it is the name, which people associate with old VB and think that the .Net one is inferior language compared to C# for example.
Learning a new language is often fun, but it can be a bit pointless. Differences between Jave, VB.Net, C# and C/C++ are not that big after all. If you would try completely different thing, like functional language as kraflab said, you would probably pick up some new skills.
It might be a good idea to dig around internet a bit and see what kind of programming concepts there are, pick one that sounds interesting and read a bit more about it. If it sounds good, try it in your game and see how it feels like. Rinse and repeat as often as you feel like.
Even better is if you have a specific problem with your code and you want to find a solution to it. Want to make your programs more loosely coupled? See if you can use dependency injection to solve it (Unity is a free library for that for example). Want to write code that is easier to maintain? See if your local library has a book about design patterns or designing software in general. Want to try writing automated tests? Play around with NUnit and NSubstitute and see what you can do with them.
You can do things in hard way (all by yourself, learning from your mistakes and trying to come up with better ways of doing things), or you can stand on shoulders of giants and learn what others have done and build on that. Both can be fun, but latter one is much, much faster.
-
Learning a new language is often fun, but it can be a bit pointless. Differences between Jave, VB.Net, C# and C/C++ are not that big after all.
Not really. Differences between Java and C# are indeed not that big and VB.Net is basically the same language as C#. But C++ is a completely different planet. It takes 8-10 years to learn C++ quite well, even if you had some Java, VB or even C# background, while a C++ programmer can teach himself Java in a month and become more proficient in it than an average Java programmer. Yes, both Java and .NET were highly influenced by C++ and they have similar syntax, but in practice they are totally different. It's like Formula 1 cars were inspired by normal cars, but it's not enough to have a driving licence to compete in Formula 1 ;).
-
Wow! Thanks a ton for all of the replies!
Right now I think I'm going to stick with VB.Net, but I'm going to use the XNA Game Studio framework as my base. Later on I think I'll start looking into learning C++.
-
It takes 8-10 years to learn C++ quite well, even if you had some Java, VB or even C# background, while a C++ programmer can teach himself Java in a month and become more proficient in it than an average Java programmer.
I think this is nonsense. It takes time to become a good programmer and has little to do with any particular language. It's more how you can apply programming concepts in a real working program, not just in theory. However C++ is a difficult language, because it lets you do things wrong in so many ways. The special feature of C++ is a lack of memory management and it's the top reason why people spend a lot of time trying to fix bugs which in turn increases development time and makes things harder. It's possible to prevent memory management issues, but it requires experience and understanding what can go wrong.
-
It takes 8-10 years to learn C++ quite well, even if you had some Java, VB or even C# background, while a C++ programmer can teach himself Java in a month and become more proficient in it than an average Java programmer.
I think this is nonsense. It takes time to become a good programmer and has little to do with any particular language. It's more how you can apply programming concepts in a real working program, not just in theory. However C++ is a difficult language, because it lets you do things wrong in so many ways. The special feature of C++ is a lack of memory management and it's the top reason why people spend a lot of time trying to fix bugs which in turn increases development time and makes things harder. It's possible to prevent memory management issues, but it requires experience and understanding what can go wrong.
Agreed, I found c++ very easy to pick up, even coming from a language with a gc and where everything was a pointer. The reason is I've been programming for a while and the concepts, while presented differently, are the same.
-
I think this is nonsense. It takes time to become a good programmer and has little to do with any particular language. It's more how you can apply programming concepts in a real working program, not just in theory. However C++ is a difficult language, because it lets you do things wrong in so many ways. The special feature of C++ is a lack of memory management and it's the top reason why people spend a lot of time trying to fix bugs which in turn increases development time and makes things harder. It's possible to prevent memory management issues, but it requires experience and understanding what can go wrong.
I think that you actually wanted to say that C++ does not have *automatic* memory management, but nevertheless the first part of your post negates the other part. If a language has features that make it more difficult than other languages, then it must take more time to "become a good programmer". I remember my own experiences with different languages. After a month of learning C++ I still didn't know what those damned pointers were about. After a month of learning VB I had written my first game. And... oh, wait. I forgot that you always put "I think this is nonsense" at the beginning of your post ;).
-
I think this is nonsense. It takes time to become a good programmer and has little to do with any particular language. It's more how you can apply programming concepts in a real working program, not just in theory. However C++ is a difficult language, because it lets you do things wrong in so many ways. The special feature of C++ is a lack of memory management and it's the top reason why people spend a lot of time trying to fix bugs which in turn increases development time and makes things harder. It's possible to prevent memory management issues, but it requires experience and understanding what can go wrong.
I think that you actually wanted to say that C++ does not have *automatic* memory management, but nevertheless the first part of your post negates the other part. If a language has features that make it more difficult than other languages, then it must take more time to "become a good programmer". I remember my own experiences with different languages. After a month of learning C++ I still didn't know what those damned pointers were about. After a month of learning VB I had written my first game. And... oh, wait. I forgot that you always put "I think this is nonsense" at the beginning of your post ;).
I think perhaps what he meant is that:
If you're a good programmer and understand how things really work, c++ won't be any more difficult than anything else.
If you're a bad programmer, c++ will seem especially difficult because it amplifies your mistakes while other languages may just eat them up.
-
An excellent summation.
-
It takes 8-10 years to learn C++ quite well, even if you had some Java, VB or even C# background, while a C++ programmer can teach himself Java in a month and become more proficient in it than an average Java programmer.
I think this is a bit of an elitist statement. Yes, C++ experience can be very useful, but claiming that a C++ programmer would be better at Java than a trained Java dev just because he knows C++ seems a fair bit... exaggerated. Though the language is rather easy to pick up as a C++ dev.
I don't like how people look down on Java as a language. I know that Notch was criticized quite a lot for writing Minecraft in Java as opposed to *cough* a REAL programming language *cough*. In the end, nobody cares for the fanboys' flamewar as long as the result works as intended.
Just to make sure I don't come off as a flaming fanboy, I know both languages and have done large projects in them. Now excuse me, I am riding my garbage collector into the sunset.
-
If you really want to learn to think about programming intuitively, pick up Haskell or Lisp. Once you have an understanding of how these work, you can more effectively utilize highly productive languages like Java, HaXe, Python, Ruby or C#.
C++, however, is a mess. It forces you to do things that you HAVE to do anyway, allowing you to do them poorly if you don't understand the complexities of the SYNTAX. Only when you do them perfectly does performance begin to exceed Java or C#. C++ leverages mundane syntactical requirements on the user with built-in pot-holes, which ultimately makes you less productive. Your programs may technically run faster in C++ (unless it's a program that runs for more than a few minutes- then Java will be faster due to run-time optimizations and caching), but the difference is genuinely arbitrary. If you really want the explicit advantages of C++, check out HaXe- it compiles to C++ with very competitive performance. C++ also offers poor auto-completion and error-checking support. Potentially resulting in a lot of wasted time.
Programming shouldn't be about syntax. It should be about productivity. Once you intuitively understand how coding works, you don't want to waste time on syntactical hoop-jumping. You want to be productive.
Otherwise, If you want practice, check out the UVA library of programming problems.
http://uva.onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8 (http://uva.onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8)
http://uvatoolkit.com/ (http://uvatoolkit.com/)
You won't learn a whole bunch about how to structure large programs, but you'll get a lot of practice that will help you understand what your code does as you're typing it- as in, you learn to debug intuitively. I think if you actually want to submit solutions they need to be in Java, which is a pretty useful language to learn.
-
I started using VB6, then I switched to C++ because people were calling VB6 names, now I've switched entirely to C#.
Language doesn't matter. Improving programming involves things that apply to all languages. That said, don't use VB6 as it doesn't have some useful OO features and being an old language the documentation, examples and tutorials online are sparse.
The easiest switch you can make, if you really want to leave VB.Net, is to C# as the two are very tightly linked. You'll have to learn new syntax, curly brackets are probably the biggest difference, but that's about it. There are sites with chart comparisons between VB.Net and C# syntax:http://www.harding.edu/fmccown/vbnet_csharp_comparison.html (http://www.harding.edu/fmccown/vbnet_csharp_comparison.html).
Java is similar to C# so getting used to C# should help any adoption of Java.
I wouldn't bother learning C++ unless you are interested in understanding low level memory management and pointers. It's useful to know, but that could be said about a lot of things. A few things I would really recommend are:
1a) Read other people's code that is well known for being written well for inspiration. Don't bother to understand how the actual program works, that takes ages, just read the code to see how they've structured and modularized the source code. Just seeing how things had been broken down into functions and split into different files.
1b) Once you realize how to structure code neatly one big trap is to spend too long doing that and to become unproductive. Strike a balance between spending ages doing things perfectly and being productive. Better to write things untidy and refactor later.
2) Learn OO concepts like inheritance and polymorphism. They aren't necessary, but they can help modularization a lot.
3) Improve at tracking down bugs and fixing them. Aside from using tools like the debugger to help, this really involves grinding on ever occurring bugs to increase XP. Bugs will always happen so getting a routine to hunt their source can be a real time saver. As a bonus 1a) should often help to reduce bugs or make them easier to track down.
-
C++, however, is a mess. It forces you to do things that you HAVE to do anyway, allowing you to do them poorly if you don't understand the complexities of the SYNTAX. Only when you do them perfectly does performance begin to exceed Java or C#. C++ leverages mundane syntactical requirements on the user with built-in pot-holes, which ultimately makes you less productive. Your programs may technically run faster in C++ (unless it's a program that runs for more than a few minutes- then Java will be faster due to run-time optimizations and caching), but the difference is genuinely arbitrary. If you really want the explicit advantages of C++, check out HaXe- it compiles to C++ with very competitive performance. C++ also offers poor auto-completion and error-checking support. Potentially resulting in a lot of wasted time.
That's what I meant. C++ is a mess. And you will not learn how to sort out this mess in a month or two (unlike Java or C#), no matter how good in the other language you are.
-
C++ is a mess.
When I learned to program I haven't had problems with the language itself. I don't feel like C++ is making any mess out of my source code.
-
When I learned to program I haven't had problems with the language itself. I don't feel like C++ is making any mess out of my source code.
I think you just don't remember the problems. It's easy to forget. If we look back, we tend to see only the good things :).
C++ is a mess. You declare a variable of a certain type and you have no idea how many bytes it has, because it's platform dependent. You would like your programs to support Unicode, but on every platform wide characters are stored differently and the new standard, which was intended to unify that, just introduces a bunch of new data types and string literals to even increase the confusion. Each and every external library you need to use has its own string implementation, so you end up with 5 different string types plus C-style zero-terminated character arrays (that themselves are a disaster). A major part of the standard C++ library is actually the C library - old and largely deprecated. It is partially replaced by STL, which is difficult to use and produces unreadable error messages. Sometimes your program would crash in some random place with a cryptic message like "Access violation at 0x27a834c reading from 0xfdfdfdfd" and you spend two weeks trying to figure out what happens. And I named just a few popular issues.
Nevertheless, I still think that C++ is the best language in the world and I'm going to laugh at Java folks ;).
-
When I learned to program I haven't had problems with the language itself. I don't feel like C++ is making any mess out of my source code.
I think you just don't remember the problems. It's easy to forget. If we look back, we tend to see only the good things :).
C++ is a mess. You declare a variable of a certain type and you have no idea how many bytes it has, because it's platform dependent. You would like your programs to support Unicode, but on every platform wide characters are stored differently and the new standard, which was intended to unify that, just introduces a bunch of new data types and string literals to even increase the confusion. Each and every external library you need to use has its own string implementation, so you end up with 5 different string types plus C-style zero-terminated character arrays (that themselves are a disaster). A major part of the standard C++ library is actually the C library - old and largely deprecated. It is partially replaced by STL, which is difficult to use and produces unreadable error messages. Sometimes your program would crash in some random place with a cryptic message like "Access violation at 0x27a834c reading from 0xfdfdfdfd" and you spend two weeks trying to figure out what happens. And I named just a few popular issues.
Nevertheless, I still think that C++ is the best language in the world and I'm going to laugh at Java folks ;).
Hey, it's not like I don't laugh at C++ folks, so feel free to laugh at us.
It's definitely a powerful language, but at some point you ask yourself whether you could do the same faster with a different language. What you describe is exactly why I stopped using C++ for my projects. I get much more done that way. It's not like I'm some crazy language fanatic - at heart I'm an engineer, and I use whatever works.
-
You declare a variable of a certain type and you have no idea how many bytes it has, because it's platform dependent.
Why do you need to know how many bytes a type has? Besides if there are platforms that have "non-standard" sizes for types like int it's really their problem.
You would like your programs to support Unicode, but on every platform wide characters are stored differently
Might be more a problem in unicode than C++. Does unicode work in other languages without similar problems?
Each and every external library you need to use has its own string implementation, so you end up with 5 different string types
Use less external libraries and more STL.
Sometimes your program would crash in some random place with a cryptic message like "Access violation at 0x27a834c reading from 0xfdfdfdfd" and you spend two weeks trying to figure out what happens.
When you learn to control C++ better bugs like this happens rarely. One of the key feature to take control of are mysterious pointers. The important lesson with pointers is a strict control of them. If you don't know where a pointer (a handle to an instance in C++) is and what is the state of it, how can you stop bugs?
-
I think VB.NET gets a bad rap among people who've never actually used it. It has inherited the idea from Basic that it's a 'beginners language' but I don't think that's really true - you need to have a fairly deep understanding of OOP in order to use it effectively. I've taught it to people in the past and there are a fair few theoretical hurdles you have to help them across - it's certainly less 'pick up and play' than the older versions of VB.
I think it only has two really meaningful drawbacks:
1. Garbage collection. Although unless you're super-concerned about performance that probably counts as a plus.
2. It's not terribly cross-platform, what with being based on an MS-owned framework and all.
That said, if you feel you must learn a new language I recommend C++. I moved to that from VB and didn't find it all that difficult to pick up the basics, although of course it's very difficult to fully master. More importantly, I found that learning C++ actually made me a much better VB.NET programmer, because it exposes you to a lot of the stuff that VB.NET hides away behind the scenes. It helped me to make sense of some of the stuff in .NET that always struck me as a bit bizarre beforehand because I could finally see where they were coming from.
-
Why do you need to know how many bytes a type has? Besides if there are platforms that have "non-standard" sizes for types like int it's really their problem.
For example, you may wish to know if your value will fit in the variable. And no, it's not "their" problem, it's your problem as a developer because you want to support as many platforms as possible.
Might be more a problem in unicode than C++. Does unicode work in other languages without similar problems?
I don't know. Java does have some Unicode issues, but that's nothing compared to Unicode issues in C++. I haven't seen other language that uses prefixes for string literals. It's like someone required from you to wear one kind of boots for a sidewalk and different ones for a road, so that you always need to have two pairs with you and switch between them when needed ;).
Use less external libraries and more STL.
As far as I know, STL does not load fonts, draw bitmaps or play sounds. For everything else (almost) I do use STL.
When you learn to control C++ better bugs like this happens rarely. One of the key feature to take control of are mysterious pointers. The important lesson with pointers is a strict control of them. If you don't know where a pointer (a handle to an instance in C++) is and what is the state of it, how can you stop bugs?
It could be shortened to "If you don't want bugs, just don't make mistakes". Yeah, that's so simple! I wonder why I didn't invent this smart technique first.
I think VB.NET gets a bad rap among people who've never actually used it. It has inherited the idea from Basic that it's a 'beginners language' but I don't think that's really true - you need to have a fairly deep understanding of OOP in order to use it effectively. I've taught it to people in the past and there are a fair few theoretical hurdles you have to help them across - it's certainly less 'pick up and play' than the older versions of VB.
It's essentially a different language. I don't know what they have in common, maybe the fact that you still use the keyword "Dim" to declare variables. You can't even port an old VB code to VB.NET because it's not backwards compatible. That's one of the reasons why I moved from VB to C++. Even Microsoft can't just shut C++ down like they did with VB :).
-
For example, you may wish to know if your value will fit in the variable.
I'm using mostly int for all number type variables, and float or double. int holds pretty big number, I haven't found a need for bigger than that. Using only int makes things easier, because it's the "universal" type for most library functions etc. I think using unsigned versions makes things just confusing even if the variable itself never has negative values.
It could be shortened to "If you don't want bugs, just don't make mistakes". Yeah, that's so simple! I wonder why I didn't invent this smart technique first.
You might be stupid-ish. But seriously, you can learn to prevent bugs that are caused by the usual reasons: careless use of pointers, memory management, out-of-bounds. Those are typical and in certain conditions very easy to do. The reason why people don't take precautions is that they strongly think they are good programmers who don't produce buggy code. They are quite arrogant I would say.
-
I'm using mostly int for all number type variables, and float or double. int holds pretty big number, I haven't found a need for bigger than that. Using only int makes things easier, because it's the "universal" type for most library functions etc. I think using unsigned versions makes things just confusing even if the variable itself never has negative values.
You're damn right - as long as you don't have to use third party code. They would infect your program with thousands of typedefs and #defines. Nothing like that would happen in Java or C#, because they use only few standardized integral types. You can live with that, of course, but that's still messy.
You might be stupid-ish. But seriously, you can learn to prevent bugs that are caused by the usual reasons: careless use of pointers, memory management, out-of-bounds.
Yes, you can learn it. And it will take you 8 years or so.
-
You're damn right - as long as you don't have to use third party code. They would infect your program with thousands of typedefs and #defines.
It's not C++'s fault that some poorly written code is using typedefs or #define (both outdated C methods).
And it will take you 8 years or so.
All it takes is a change of attitude. There is always hope for that since C++ doesn't forgive stupidity. If you do stupid things in C++ it's you who suffer.
-
All it takes is a change of attitude. There is always hope for that since C++ doesn't forgive stupidity. If you do stupid things in C++ it's you who suffer.
Sounds like the perfect language for a masochist.
C++ isn't worth learning unless there is a professional need for you to do so.
-
C++ isn't worth learning unless there is a professional need for you to do so.
That's a pretty strong statement for something that's basically just individual preference. I have to use VB.NET at work, but when I'm programming recreationally I typically choose of my own free will to use C++ (out of the five-and-a-bit languages I'm reasonably competent with). Sure, there's more that can go wrong with it and it can take a bit longer to write something than it might do in another more friendly language, but I never feel that I have to compromise with C++. If I want to write high-performance code that will run on pretty much anything then there is nothing intrinsic to the design of the language that stops me from doing that.
Plus, as I said before, I think that the greater depth of knowledge and discipline that C++ demands has made me a better programmer overall even in completely different languages, so I would say it's definitely worthwhile learning even if only for that.
-
...but when I'm programming recreationally I typically choose of my own free will to use C++ (out of the five-and-a-bit languages I'm reasonably competent with).
You know, I have to agree with this. I can use quite a few languages, but when time is not an issue I think I enjoy writing c++ the most. Maybe it's because sometimes c++ feels like a syntax puzzle ;) The game-development process is it's own game!
-
It's not C++'s fault that some poorly written code is using typedefs or #define (both outdated C methods).
I haven't seen a library that does NOT use typedefs or #defines, so again: everything will be very simple if you are only using your own perfectly clean code, but as soon as you decide to use anything else, you are doomed to C++'s data type hell.
C++ isn't worth learning unless there is a professional need for you to do so.
When I was in school, many kids used to say that maths is not worth learning. Well, people who are afraid of any mental effort are not worth being listened to ;).
-
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 (https://vimeo.com/36579366) 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).
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
It makes complete sense that it mucks up syntax if you try to use a c library in c++.
Wrong.
-
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 :P
-
Look, c is terrible. I hope we can all agree on that :P
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).
-
- 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.
-
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.
-
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.
-
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).
-
GUI class can be more than just a wrapper.
Do you mean it can be even more messy?
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.
Does it use black magic to eliminate the need to convert from SDL's data types? Does it prevent my IDE from showing me their internal data types? And most important of all, is it so perfect that I'll never need to debug it?
-
no JavaScript haters or lovers here? :)
I come from a C/Java background, dabbled in Python/Perl/Ruby and finally landed in JS land. I've been hacking JS for the last few years, and it took me at least 12 months to get comfortable with it.
Although JS is minimal when it comes to language concepts and barely has a standard library, it takes a while to fully grasp the language (in the end it's closer to Scheme then to Java).
It's cosy, minimal, functional. Probably one of the few languages which you can fully grasp. I feel secure in JS, because I truly understand it. And while coding, it's easy to start with something functional and evolve it towards being object-oriented (if needed and sensible).
I would recommend this as a second language. It has a tiny standard library and only a few language concepts.
ps.: for a decent intro to JS see http://javascript.crockford.com/javascript.html (http://javascript.crockford.com/javascript.html)
-
Do you mean it can be even more messy?
Actually with good class design you can make traditional C library more useful than it was.
Does it use black magic to eliminate the need to convert from SDL's data types
I don't know what is your problem with SDL data types, but it must be something special, because I never had any problems with SDL data types.
-
I don't know what is your problem with SDL data types, but it must be something special, because I never had any problems with SDL data types.
I'm not saying this is a huge problem (I have already mentioned more serious problems with C++ earlier in this thread). However, having 50 data types instead of 5 always makes your life more complicated.
-
For me, personally, Java was the best thing that ever happened to me. I found it to be the perfect language to actually pick up some serious coding ideas.