quote:Originally posted by alby
Oh, well, I am still a noob in coding, but honestly, I wouldn't start with C++ since it's pretty low level language.
What?! It's just another OO C, which is almost exactly what Java and C# are. The only thing you -MAY- miss in C++ is garbage collection, which IMO is more trouble than it's worth [you know better than some dumb algorithm when you don't need your data anymore]. If you love your GC, try D, which is like C++ with all the warts removed. Also, C is much much nicer than C++.
Whatever you do, don't get into Java. The world can do with a few less Java programmers. Java isn't strongly typed, which is painful [recently a friend couldn't work out how to convert a string to an integer- turns out you can subtract zero to do this. Just too strange].
Erm, if you feel like having some fun, try LISP. It's probably a good idea to learn LISP even if you plan to program something else. If you're a mad genius, you could learn something wacky like Haskell, but depending what you plan to do, that might not be that useful to you. This is a very good LISP book.
But my recommendations, for most heavy coding, are C and D. If you don't need blistering graphics or that Schr�dinger's equation solved yesterday, Python is a very good language. Yes, even for games.
was put impeccably into words at DebianDay for me last Saturday, by Knut Yrvin of Trolltech - adults try something once, fail, and then are like "ffs this doesn't work". Children try, fail, and then try again, and succeed - maybe on the second, or even fifth retry. But the thing is that they keep at it and overcome the problems in the end.
Posts: 3146 Reputation: 43
32 / /
Joined: Jan 2003
RE: Good programming language..
quote:Originally posted by Verte
[you know better than some dumb algorithm when you don't need your data anymore]
err... garbage collection disposes of objects when they aren't referenced anywhere anymore, meaning they can't possibly ever be accessed
Spoiler:
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
quote:Originally posted by Verte
[you know better than some dumb algorithm when you don't need your data anymore]
err... garbage collection disposes of objects when they aren't referenced anywhere anymore, meaning they can't possibly ever be accessed
That's what they should do. But, if you use pointers anywhere, you've got to be very careful with GC. For example, if you pass a pointer variable to a subroutine, and the subroutine uses a temp variable to represent that variable inside, assigns a new object on the heap to the temp variable, and then the temp variable goes out of scope, most GCs will free the object. In cases such as these, you've got to increment the reference counter by hand, which is to say that you're essentially doing manual garbage collection anyway. This is because Garbage collection typically only tracks direct assignments, and where one variable may reference an object indirectly [such as through an array of pointers or references] the GC will not count the [second-order] reference.
IMO, you know when you're done with data, you deal with it.
was put impeccably into words at DebianDay for me last Saturday, by Knut Yrvin of Trolltech - adults try something once, fail, and then are like "ffs this doesn't work". Children try, fail, and then try again, and succeed - maybe on the second, or even fifth retry. But the thing is that they keep at it and overcome the problems in the end.
Posts: 3146 Reputation: 43
32 / /
Joined: Jan 2003
RE: Good programming language..
quote:Originally posted by Verte
That's what they should do. But, if you use pointers anywhere, you've got to be very careful with GC. For example, if you pass a pointer variable to a subroutine, and the subroutine uses a temp variable to represent that variable inside, assigns a new object on the heap to the temp variable, and then the temp variable goes out of scope, most GCs will free the object. In cases such as these, you've got to increment the reference counter by hand, which is to say that you're essentially doing manual garbage collection anyway. This is because Garbage collection typically only tracks direct assignments, and where one variable may reference an object indirectly [such as through an array of pointers or references] the GC will not count the [second-order] reference.
IMO, you know when you're done with data, you deal with it.
thats why GC languages don't use pointers, they use references
Spoiler:
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
the game.
quote:Originally posted by Verte
That's what they should do. But, if you use pointers anywhere, you've got to be very careful with GC. For example, if you pass a pointer variable to a subroutine, and the subroutine uses a temp variable to represent that variable inside, assigns a new object on the heap to the temp variable, and then the temp variable goes out of scope, most GCs will free the object. In cases such as these, you've got to increment the reference counter by hand, which is to say that you're essentially doing manual garbage collection anyway. This is because Garbage collection typically only tracks direct assignments, and where one variable may reference an object indirectly [such as through an array of pointers or references] the GC will not count the [second-order] reference.
IMO, you know when you're done with data, you deal with it.
thats why GC languages don't use pointers, they use references
A reference is treated much as a pointer internally. Compiled code only contains memory locations, not variable names. References are often more convenient, but they suffer the same problems with GC.
How about overlapping reference arrays, which are often the easiest and most sane way to hold data that needs to be viewed in two different ways? Again, the references aren't distinct but they aren't direct, so when the array they were created in [which was possibly intentionally temporary] passes out of scope, they disappear, and the big array you were holding them in now has a heap of invalid references that will segfault when you try to use them.
was put impeccably into words at DebianDay for me last Saturday, by Knut Yrvin of Trolltech - adults try something once, fail, and then are like "ffs this doesn't work". Children try, fail, and then try again, and succeed - maybe on the second, or even fifth retry. But the thing is that they keep at it and overcome the problems in the end.
quote:Originally posted by Verte
[recently a friend couldn't work out how to convert a string to an integer- turns out you can subtract zero to do this. Just too strange].
That would be subtracting the character '0'. That's possible in C/C++ as well.
For example:
code:int atoi(const char * pstr) {
int i;
int nRet = 0;
for (i = 0; ; i++) {
if (pstr[i]==0)
break;
if (pstr[i]>='0' && pstr[i]<='9') {
nRet*=10;
nRet+=pstr[i]-'0';
}
else return 0;
}
return nRet;
}
quote:Originally posted by Verte
[recently a friend couldn't work out how to convert a string to an integer- turns out you can subtract zero to do this. Just too strange].
That would be subtracting the character '0'. That's possible in C/C++ as well.
It may be possible, but there are also conversion functions, or where one is not required, a direct cast.
was put impeccably into words at DebianDay for me last Saturday, by Knut Yrvin of Trolltech - adults try something once, fail, and then are like "ffs this doesn't work". Children try, fail, and then try again, and succeed - maybe on the second, or even fifth retry. But the thing is that they keep at it and overcome the problems in the end.
Posts: 1791 Reputation: 25
33 / /
Joined: Jun 2004
O.P. RE: Good programming language..
quote:Originally posted by Knuckles
Some people might shoot me for this but I find C# a really easy language to learn and have found plenty of video tutorials for it located on MSDN. The fact that Visual C# 2005 Express Edition is free and helps you a lot with programming as the IDE practically does it for you.
Hope this helps.
I've been going there, but I've only found one C# video tutorial entitled "Introduction to the C# Programming Language"
I've learned quite a bit with the video (and the additional integral article).. Can you link me to any other video tutorials? Or even just text tutorials but that start from the bottom.. I can only find more advanced stuff on the MSDN library :\ Thanks
This post was edited on 06-27-2007 at 03:09 PM by Jhrono.