Programming Languages
Hey everyone. I'm interested in relearning some programming, and wanted some suggestions about what language I should learn first. I know there are some programmers that frequent these forums, so now's your chance! I haven't done any programming in about 7 years, and that was with Turbo Pascal (6.
Hey everyone. I'm interested in relearning some programming, and wanted some suggestions about what language I should learn first. I know there are some programmers that frequent these forums, so now's your chance!
I haven't done any programming in about 7 years, and that was with Turbo Pascal (6.x?) for DOS.
I am not initially interested in compiling anything for Linux, just Windows. However, it would be a nice feature if the language was either the same of similar on multiple platforms.
I will be recieving a free eval copy of Visual Studio .NET 2003 from the Windows Server 2003 launch event at the end of the month, and unless I am mistaken, that package will include C#, C++, Visual Basic, and J#. I think that I would like to learn one of these languages, and I have heard great things about C/C++, so that would probably be my starting point.
I don't really recall any of the language that I learned years ago, but I do recall some concepts, so hopefully the learning curve will not be too steep.
I know that Java/J# will probably be highly recommended, but I am curious to the future of the language, with the ongoing litigation between MSFT and Sun, and what impact that will have on the language. Also, while I'm asking about expected life expectancy of the languages, I would like any input on other programming languages life expectancy as well.
I haven't done any programming in about 7 years, and that was with Turbo Pascal (6.x?) for DOS.
I am not initially interested in compiling anything for Linux, just Windows. However, it would be a nice feature if the language was either the same of similar on multiple platforms.
I will be recieving a free eval copy of Visual Studio .NET 2003 from the Windows Server 2003 launch event at the end of the month, and unless I am mistaken, that package will include C#, C++, Visual Basic, and J#. I think that I would like to learn one of these languages, and I have heard great things about C/C++, so that would probably be my starting point.
I don't really recall any of the language that I learned years ago, but I do recall some concepts, so hopefully the learning curve will not be too steep.
I know that Java/J# will probably be highly recommended, but I am curious to the future of the language, with the ongoing litigation between MSFT and Sun, and what impact that will have on the language. Also, while I'm asking about expected life expectancy of the languages, I would like any input on other programming languages life expectancy as well.
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
Quote:LOL, tricky! You're saying since it goes outta local "scope" there, it's not traceable anymore by the local malloc/free routines right?
It's exactly the fact that it leaves the local scope that makes it so hard for the compiler to analyze. Yes, the pointers themselves will die with the function, but I also returned one of the pointers to the calling function, so the object itself may still be used elsewhere. Remember that in C/C++ the pointer is quite separate from the object itself. The memory leak is that I only want to keep one of the two objects after leaving the function. Without returning it, I no longer have a pointer to the other object... thus I can't access it and it is leaked.
Quote:(The vars BOTH die anyhow at procedural termination & later at application death HWnd.Destroy method. Still, that code you put down should at least have 'warning' from compiler regarding malloc/free or new/delete stuff just to keep you on your toes.)
Well, if your heap manager is good (like in Win2k or WinXP), then ALL memory allocations will be freed when the program exits. (I am avoiding Win32 specifics like HWnd, since this topic applies to all OS's.) So for a short-running program, you could neglect your free-ing responsibilities completely, and let the heap manager recover it when you're done. (Win9x is not as good about this, which is a big part of it's instability.) Memory leaks don't usually become a problem until you have an app that is going to run for a long time - eg. services, daemons, and all those useless tray-apps people love.
Quote:Heck, compiling in C/C++ IS a given performance penalty man, lol... you know it, I know it... anything of size, relative term, you might as well start compile, go eat lunch, & come back & only be 1/2 done... lol!
I'm talking about run-time here, not compile time. Of course the extra analysis at compile time will take longer, but once it's compiled you're done. But when you have run-time performance hits, then you and all of your users have to deal with it. All of that extra work when your program is running will add up quickly, whether from the extra code your smart compiler put in or from the garbage collector or "delinter" trying to keep tabs on everything. I'm all about lean-and-mean programming...
But then, I'm currently taking a course entitiled "Code Generation and Optimization", which is all about low-level optimizations, so maybe my perspective is a little skewed...
It's exactly the fact that it leaves the local scope that makes it so hard for the compiler to analyze. Yes, the pointers themselves will die with the function, but I also returned one of the pointers to the calling function, so the object itself may still be used elsewhere. Remember that in C/C++ the pointer is quite separate from the object itself. The memory leak is that I only want to keep one of the two objects after leaving the function. Without returning it, I no longer have a pointer to the other object... thus I can't access it and it is leaked.
Quote:(The vars BOTH die anyhow at procedural termination & later at application death HWnd.Destroy method. Still, that code you put down should at least have 'warning' from compiler regarding malloc/free or new/delete stuff just to keep you on your toes.)
Well, if your heap manager is good (like in Win2k or WinXP), then ALL memory allocations will be freed when the program exits. (I am avoiding Win32 specifics like HWnd, since this topic applies to all OS's.) So for a short-running program, you could neglect your free-ing responsibilities completely, and let the heap manager recover it when you're done. (Win9x is not as good about this, which is a big part of it's instability.) Memory leaks don't usually become a problem until you have an app that is going to run for a long time - eg. services, daemons, and all those useless tray-apps people love.
Quote:Heck, compiling in C/C++ IS a given performance penalty man, lol... you know it, I know it... anything of size, relative term, you might as well start compile, go eat lunch, & come back & only be 1/2 done... lol!
I'm talking about run-time here, not compile time. Of course the extra analysis at compile time will take longer, but once it's compiled you're done. But when you have run-time performance hits, then you and all of your users have to deal with it. All of that extra work when your program is running will add up quickly, whether from the extra code your smart compiler put in or from the garbage collector or "delinter" trying to keep tabs on everything. I'm all about lean-and-mean programming...
But then, I'm currently taking a course entitiled "Code Generation and Optimization", which is all about low-level optimizations, so maybe my perspective is a little skewed...
