|
I agree that there is a growing group of ignorant programmers afoot. In my opinion, this has more to do with companies valuing cost/education over quality/experience than just ignorant programmers.
I started out as an ignorant programmer, but was fortunate enough to work with a quality programmer who "taught me the ropes". I consider myself to be 75% of the time a high quality programmer and the other 25% I just look like a high quality programmer while staring with wonder at code I wrote 6 months ago. (WTF was I thinking?)
I think the assumption that new tools making things easier will create more ignorant programmers is false. If anything, it will enable high-quality programmers to develop quality code faster and with less unnecessary overhead. We can still use best-practises, but we are now presented with more options to enable us to expedite our projects. There are bad-programmers programming in WTL, MFC, ATL, C++, VB, Java, etc. Adding more languages will not change this fact.
My current project has lasted almost 2 years. Most of that time was spent developing the back-end data management system, rules, processing, etc. The remainder of the time was spent developing an MFC front-end. The front-end is the part the average user cares about, but the back-end system was the most critical to overall success. I had to spend much of my GUI time developing custom-controls and other "fancy" interface stuff, tracking down little input bugs, etc. If I had access to a powerful tool for developing the GUI that would have limited my exposure to some of these issues, the back-end system could have been further developed, thus improving the overall product. A small performance cost in the GUI would not have mattered.
I welcome the addition of new languages and tools, I just realize they are only tools. In the proper hands they will work wonders, in ignorant hands they may cause fewer problems that earlier languages/tools.
Just my $0.02.
Thanks,
Matt Gullett
PS. None of the new languages/tools prevent me/us from using good old C++, STL, etc.
|
|
|
|
|
Pointers are for code monkies...and "garbage collection and sandbox" are for developers that want to solve their clients' problems rather than mess with memory tricks.
I know what pointers are. I know how to use them. Yep, there are somethings that you can only do (or do quickly) with pointers. But in the rest of the cases, I want my language and framework to help me solve the problem, not get in my way.
--Tim
|
|
|
|
|
Pointers do not get in the way, the provide an *option* for management of memory. This code monkey can't think of another way to do a lot of the stuff I do elegantly.
kaleid wrote:
But in the rest of the cases, I want my language and framework to help me solve the problem, not get in my way.
How does the *option* of dynamic memory allocation get in your way ? Is it too confusing to have more than one way of doing things ?
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Oops, you're right, I misspelled 'monkeys'. Anyway:
Christian Graus wrote:
Pointers do not get in the way, the provide an *option* for management of memory. This code monkey can't think of another way to do a lot of the stuff I do elegantly.
Let's compare to say, MFC/C++. There's not much of an option as far as pointers go. You _have_ to use them if you want to get anything done. Right, you don't have to allocate memory dynamically if you don't want to...but if you do you have a bunch of code in there to do clean up and allocation that the compiler or runtime should be smart enough to do.
That is why I'm glad to see that C# and the .NET platform offer memory management (gc), but still allow you unmanaged access to raw memory, should the need arise.
#end troll
--Tim
|
|
|
|
|
But building the garbage collection and memory managment into the common runtime should slow the program(s) down, since they have someone else doing their dirty work for them... who knows if .NET's memory management is optimized? If it is, great...but if not, then that's a performance hit that you can maybe code away if you're clever...
Another reason why garbage collection by the common runtime should slow programs down is that the programs now have to call out to the runtime each time the garbage collection needs to happen, and then switch back into the program code to continue on... I smell lots of expensive context-switches on the part of the processor. Maybe it's not an issue with the blazing-fast processors available now... 
Sincerely Yours,
Brian Hart
"And that's the news from Lake Wobegon, where all the women are strong, the men are good-looking, and the children are above-average." - Garrison Keillor
|
|
|
|
|
Brian Hart wrote:
I smell lots of expensive context-switches on the part of the processor
There are no context switches - the runtime is an inproc dll. Questioning whether the garbage collection is optimized isn't a good idea. I don't know you, although I would bet that the caching system alone was written by guys more knowledgeable about it than you or I.
I think that tools like C# and Java are great - they're RAD tools, but much more powerful than the likes of VB. It's been my experience that these tools have only 3 disadvantages:
1) They can't make use of low-level functionality. For most "normal" apps (the benefits of RAD tools are most evident in "normal" apps anyway), this isn't necessary. If you're not making a "normal" app, use another tool.
2) Inner, inner inner loops. I mean the ones making tens of thousands of iterations. This may cause performance to become unacceptable, but most of these cases also fall under case 1. If you're worried about any other aspect of performance, don't be. The extra time you spend writing in a lower level tool probably won't be gained back by the program running faster for many years of continual use.
3) Memory footprint. I find this to be the most annoying - I mean come on! a 20 MB footprint for a "Hello World" program! However, in situations such as a web server, the optimizing aspect of the GC usually displaces the hit of using a large footprint.
Yury Sulsky
|
|
|
|
|
Looks like this is how the collection is managed:
To optimize the performance of the garbage collector, the managed heap is divided into three generations: 0, 1, and 2. The runtime's garbage collection algorithm is based on several generalizations that the computer software industry has discovered to be true by experimenting with garbage collection schemes. First, it is faster to compact the memory for a portion of the managed heap than for the entire managed heap. Secondly, newer objects will have shorter lifetimes and older objects will have longer lifetimes. Lastly, newer objects tend to be related to each other and accessed by the application around the same time.
The runtime's garbage collector stores new objects in generation 0. Objects created early in the application's lifetime that survive collections are promoted and stored in generations 1 and 2. The process of object promotion is described later in this topic. Since it is faster to compact a portion of the managed heap than the entire heap, this scheme allows the garbage collector to release the memory in a specific generation rather than release the memory for the entire managed heap each time it performs a collection.
In reality, the garbage collector performs a collection when generation 0 is full. If an application attempts to create a new object when generation 0 is full, the garbage collector discovers that there is no address space remaining in generation 0 to allocate for the object. The garbage collector performs a collection in an attempt to free address space in generation 0 for the object. The garbage collector starts by examining the objects in generation 0 rather than all the objects in the managed heap. This is the most efficient approach, because new objects tend to have short lifetimes and it is expected that many of the objects in generation 0 will no longer be in use by the application when a collection is performed. In addition, a collection of generation 0 alone often reclaims enough memory to allow the application to continue creating new objects.
After the garbage collector performs a collection of generation 0, it compacts the memory for the reachable objects as explained in Releasing Memory earlier in this topic. The garbage collector then promotes these objects and considers this portion of the managed heap generation 1. Because objects that survive collections tend to have longer lifetimes, it makes sense to promote them to a higher generation. As a result, the garbage collector does not have to reexamine the objects in generations 1 and 2 each time it performs a collection of generation 0.
After the garbage collector performs its first collection of generation 0, and promotes the reachable objects to generation 1, it considers the remainder of the managed heap generation 0. It continues to allocate memory for new objects in generation 0 until generation 0 is full and it is necessary to perform another collection. At this point, the garbage collector's optimizing engine determines whether it is necessary to examine the objects in older generations. For example, if a collection of generation 0 does not reclaim enough memory for the application to successfully complete its attempt to create a new object, the garbage collector can perform a collection of generation 1, then generation 0. If this does not reclaim enough memory, the garbage collector can perform a collection of generations 2, 1, and 0. After each collection, the garbage collector compacts the reachable objects in generation 0 and promotes them to generation 1. Objects in generation 1 that survive collections are promoted to generation 2. Because the garbage collector supports only three generations, objects in generation 2 that survive a collection remain in generation 2 until they are determined to be unreachable in a future collection.
|
|
|
|
|
But building the garbage collection and memory management into the common runtime should slow the program(s) down, since they have someone else doing their dirty work for them...
Don't you, people, think that malloc/alloc pair is psychologically similar to GC? Think about it: instead of allocating a page of memory directly from OS we are relying on a memory manager with lists of allocated and deallocated blocks, thread safeguards, small/large memory blocks threshold, etc, etc, etc. It does not bother you, does it?
The point is: the whole GC "problem" is just a psychological barrier. Some days ago, when I was thinking about the whole GC idea, I've realized that I don't care about the memory allocation efficiency in 90% of code I'm usually writing. The rule of thumb is to optimize on the critical path. A large portion of any GUI app is not on the critical path and will be OK even with allocation of shared memory file on a remote server (OK, you'll need to check it first  ) So, CLR's memory manager is going to be OK in many many cases. And for the rest we still have C++ and asm, don't we? It's not like in Java when you do not (ideally) have anything besides the interpreter.
Actually, see Reno Tiko in the "Bad Trend" thread.
I think this is what many felt when C, Pascal or whatever the language was that came after Assembly. Then when OO stuff came out like C++ people used the same argument to favor coding in C. And examples like this could go on and on with Java, C#, etc.
MK
|
|
|
|
|
kaleid wrote:
want my language and framework to help me solve the problem, not get in my way.
Englightment me! why would a language using pointers get in your way?
The cool thing about C++ is you *dont* necessarily have to use pointers, you can get away with using references, apart from some Win32 API calls.
Normski. - Professional Windows Programmer
|
|
|
|
|
I put:
Making programming easier means dumber programmers will be writing apps (meaning poorer quality apps)
I don't think garbage collection in itself will make bad apps, although I certainly would prefer to manage my own memory. What's more at issue is that as languages contain 'features' to make programming easier instead of features to make the language more powerful, the focus shifts and a *perception* that it is easy to program in a modern language will result in more bad programmers, and a lack of understanding in management will result in falling wages for programmers in general, because it will be seen as a less technical and more keyboard entry type job.
I agree with Chris though - garbage collection is for weenies. Anyone too stupid to work out what to do with a pointer should stick to management.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Real programmers don't fear pointers; it's just a number. Are you afraid of the phone book? No? You will be.
Real programmers can clean up after themselves - garbage collection is for spoiled brats who've never had to take responsibility for anything ever in their pathetic little lives. If you use it, put it back when you're done. Someday, Mommy won't be around to clean up after you.
Frameworks ensure that your app looks just like every other app. Yay! Maybe round buttons will help? Nope, sorry.
(oh, b.t.w.,  )
-c
Smaller Animals Software, Inc.
|
|
|
|
|
I take it this thread is meant to spark some sort of debate. Well, let's get it on!
1. Imagine if C++ didn't have stack allocation of objects, just like Java or C#, where all objects must be allocated with new. Since C++ also doesn't have a garbage collector, you'd then need to remember to call delete for every object allocated. That would really suck! Everytime you'd need a string object, you'd need to do: string str = new string;, then you'd need to use the * and -> notation, and finally call delete str; before the block's end. Thankfully, the vast majority of objects used inside a typical C++ program can be allocated on the stack which: (a) cleans the objects memory, (b) calls the object's destructor, and (c) is very fast. However, for those times when the stack can't be used because the object needs to live outside the block, you need to use new and then remember to call delete afterward. I guess my point is that garbage collected languages completely eliminate this requirement, thereby making the code smaller and easier to write.
2. There are times in C++ when you need to retrieve an object from a function. The most common example is a string object. In garbage-collected languages this is a trivial operation since only the object's "handle" is passed back. In C++, it's more complicated because you want to avoid the overhead of calling the object's copy constructor. So you have to resort to elaborate schemes such as Copy-On-Write to minimize the overhead.
3. In C++ when you have a method that returns a pointer to an object (i.e., to avoid the overhead of copying), there's nothing to indicate whether this pointer should be deleted or not (short of making it const). Even worse, there's nothing to stop you from deleting that pointer and causing other code to break. With garbage collected languages this is not an issue since you're not allowed to delete anything. Only the gc knows when things are safe to be deleted.
4. I love C++! It has great features which I miss in Java and VB. However, as good as I've gotten at manual memory management, with smart-pointers, etc., I'd much rather have it all be done automatically for me, even if causes my app to run a little bit slower. Now, if I could have a language like that which would also give me deterministic finalization, I'd be in programming heaven.
Regards,
Alvaro
|
|
|
|
|
Personally I don't have any extreme view on the subject of GC. I don't think C++ language itself is against the concept of GC. GC may not be part of formal / standard C++ language spec, but there are dozens of C++ GC implementations we can find on the web.
The thing that really bothers me about GC driven frameworks is the absence of deterministic finalization, it's so convenient to use.
// Fazlul
Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com
|
|
|
|
|
Fazlul Kabir wrote:
Personally I don't have any extreme view on the subject of GC. I don't think C++ language itself is against the concept of GC. GC may not be part of formal / standard C++ language spec, but there are dozens of C++ GC implementations we can find on the web.
Stroustrup actually considered garbage collection for C++, but knew he had to deliver a language within 5% of the speed of C or it would be stillborn. Given that it's obvious GC results in a speed hit, I think having the option to add the facility is the best solution all round.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Christian Graus wrote:
Stroustrup actually considered garbage collection for C++,
Exactly, here is the link where he talks about GC in C++. The link also discusses how C++ supports programming techniques that allows memory management to be safe and implicit without a garbage collector.
// Fazlul
Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com
|
|
|
|
|
Testify to that, bro. 
Sincerely Yours,
Brian Hart
"And that's the news from Lake Wobegon, where all the women are strong, the men are good-looking, and the children are above-average." - Garrison Keillor
|
|
|
|
|
Chris Losinger wrote:
Real programmers don't fear pointers;
<rant>
And real men don't fear knives; but... if i've got a fork handy, then i'll use that, rather than the knife, to eat with. Similarly, even though i can usually get by with a small flat-head screwdriver, having one that fits the screw i'm using is nice.
Pointers, gotos, long jumps, in-line assembler, mice, GUIs, modular languages, OO languages, structured exception handling, garbage collection, self-modifying code, jump tables, loops, recursive routines, interpreted languages...
The toolbox for programmers is large. Arguing that one tool should never be used, or that another should always be used is pointless, and insulting to the rest of us. If i'm developing a web page and the design calls for an animation, i could write a specialized native-code plugin, or i could just use an animated [.png/.gif] file. Depending on the situation, either might be appropriate, or one might be terribly, terribly wrong.
Finally, please remember: it is always a danger if the person using a language/library/framework does not understand what he/she is doing. Miss-using pointers is not the only way to corrupt data.
</rant>
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
farewell goodnight last one out turn out the lightsSmashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
You are perfectly right.
Nothing other to say.
|
|
|
|
|
The poll has been up for most of the day, 128 people have voted, but only two comment have been submitted.
I'm amazed.
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Probably because CP was unusably slow last night. I would have been the first comment if I could get the page to load. I could read, but when I hit new comment it would just time out.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Someone had to say it.
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
.NET = more breasts at the office?
Change is gooood. 
/Magnus
|
|
|
|
|
"No one knows what power lies yet undeveloped in that wiry system of mine."
Ada Lovelace 1815-1852
|
|
|
|
|
Cup-size too.
Nish
p.s. last time too it was you who started it and me who made into an epic thread, so thought this would be symbolic
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Heaving breasts are even better
Normski. - Professional Windows Programmer
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
