|
Martin Marvinski wrote:
When the tools start hiding how things actually work you always lose control.
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.
The thing to realize is that a specific language is not for everyone and not for every project. Use which ever one you feel fits your individual and project's needs. If we stopped making tools that are easier to use for fear of losing control then we won't be bettering ourselves in this profession since we'll be stuck with archaic tools. I'm for anything that'll make me productive and still allow the project to meet its functional/non-functional requirements thus greatly reducing implementation time. I'd rather go home at 5:00pm than work 12-14 hr days trying to find resource leakage issues, etc. when a tool could automatically take care of that for me.
If I were developing a web server, a 3D game engine, etc. I wouldn't even think about using C# or Java to do it. However, if the client wanted a simple way to edit some columns within a table and to perform some simple validation, then I'd use C# or VB to bind the datasource to a data grid. I could care less how much more efficent it would be to write it in C++, etc. in that instance whereas I would be concerned about efficency issues in the web server and 3D engine projects.
|
|
|
|
|
I agree with most of what you said, but I wouldn't compare the current trend to the move from C to C++. After all, most of us were using C++ principals in C before C++ was available. ie: creating a structure with pointers to functions to emulate a class - C++ didn't change how we did things (in those respects), just provided a better way to implement what we were already trying to do - and for the most part left us with all the control. As long as we build solid classes that extend the language, we aren’t using the same old archaic tools. We get to choose our level of abstraction.
Joshua Page
josh@terminaltechnologies.com
"The software required Windows 98 or better, so I installed Linux...."
|
|
|
|
|
I agree, and you've said it very well.
As much as I love C++ and Visual C++, I can't help but marvel at how great it is to work with Visual Basic (the tool) when it comes to small database-centric apps and components.
Regards,
Alvaro
|
|
|
|
|
In my experiences with the Visual Studio.NET beta 1 and 2, the tools are much less likely to 'hide' stuff from you. MFC, Visual C++, and especially COM tools--those hid things.
The tools in Visual Studio.NET generate code. That's it. You can look at the code, change it, whatever.
You can write stuff for the .NET platform with notepad and a the command-line compiler. That's all you need. (Now, I'd prefer to use the project management tools, the source control, GUI layout tools, etc...but one doesn't have to).
--Tim
|
|
|
|
|
Just want to comment that mfc doesn't hide anything. The source code is shipped with Visual C++. You can browse through it, even copy and paste parts of it if you find errors or problems.
swine
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
I see a couple of opposing trends in C++-like software development currently.
There is the standards driven trend, using ANSII/ISO C++, supported by open source, multi-platform libraries like BOOST, and WxWindows. This approach requires that you can (a) use a text editor, and (b) actually understand the language that you are working with. You have *total* control over your app, and are never tied to a particular platform, be that a hardware or software placform.
The other powerful trend, is what I always imagine as the marketing department guy, or some monkey from management banging away at a copy of Visual Basic. (Insert IT department and C# if it fits.). You are usually tied to one platform, and soon find yourself banging your head against something your tool won't let you do.
As soon as tools start forgiving ignorance, ignorance is what you get. I'm blown away by the number of Visual C++ programmers that can't even create classes without the aid of the IDE. I can't trust software written by people who don't have a working understanding of their software. The latest, flashy looking, but horribly designed offerings from many software houses are a testament to this.
Tools can make your life easier. Tools can give you leverage. But when tools try to make your life easier by hiding implementation details, I would argue that they are doing us all a disservice...
Am I just a grumpy old(26!)-school programmer?
Could be...
What do you think?
-- Leon
|
|
|
|
|
*Leon* wrote:
As soon as tools start forgiving ignorance, ignorance is what you get.
I think I'm going to have to use that as a quote - it is a simple truth, and all the more powerful for it.
*Leon* wrote:
I'm blown away by the number of Visual C++ programmers that can't even create classes without the aid of the IDE.
You're kidding, surely ? That's PATHETIC.
*Leon* wrote:
Am I just a grumpy old(26!)-school programmer?
I'm 33 - if you're old school, I think I need to be put down. But I agree with you totally.
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:
*Leon* wrote:
I'm blown away by the number of Visual C++ programmers that can't even create classes without the aid of the IDE.
You're kidding, surely ? That's PATHETIC.
I see that all around me every day. Actually some can't even do that because they don't know there is an IDE aid for classes - they only know that classes have dialogs and so they insert a dialog and then hit Ctrl+W to create a class with class wizards, unaware that they could create a generic class instead using the menu.
Oh well...
|
|
|
|
|
*Leon* wrote:
Am I just a grumpy old(26!)-school programmer?
As a young man (31  ), I agree with you 100%.
I vote pro drink ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
