|
I picked "Better tools means higher productivity".
Some assumptions behind C#/.NET:
1) we have enough spare CPU cycles to give the computer more of the grunt work, and
2) the new CLR provides way more functionality at a higher level than C++/Win32 API does.
Are these assumptions right or wrong? In the final analysis, the market will tell us which one developers prefer, but I think the success of Java and VB already tell us what most developers will lean toward.
For myself, I remain a C++ junkie. I'll transition to C# as I get the time.
CodeGuy
The WTL newsgroup: over 1100 members! Be a part of it. http://groups.yahoo.com/group/wtl
|
|
|
|
|
I've picked "Making programming easier means dumber programmers will be writing apps".
Thinking about working on predefined platform, your opinion is correct.
Productivity means the choice of the market.
But my point of view is rather differenct.
I have a vision to be able to design and build a new platform like "X-Box" or "Palm" someday.
And I hope not to be in subordination to MS(or any other big brother) after 10 years.
C#, one of the coolest language until now on this planet, is good choice but I don't think it will enable me to realize my illusion.
Every engineer and developer has his own standpoint and that's the difference.
Regards,
Ryan
-p.s I'm a memeber of WTL groups too. 
|
|
|
|
|
|
agreed 
"No one knows what power lies yet undeveloped in that wiry system of mine."
Ada Lovelace 1815-1852
|
|
|
|
|
I think this is a bad trend. When the tools start hiding how things actually work you always lose control. Remember it's always a trade off between ease of use vs. power. I don't want to lose the respect of being a programmer, because I might if every language becomes like Visual Basic. I don't want something such as garbage collection because I can free memory myself.
This is a dangerous trend because if it continues the only real programmers will be at MS and everyone else will be VB losers.
<marquee style="filter:blur(Add=1, Direction=90, Strength=4)">I ![Heart | [heart]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/love.gif) Microsoft
|
|
|
|
|
Martin Marvinski wrote:
When the tools start hiding how things actually work you always lose control.
Absolutely agreed.
Martin Marvinski wrote:
I don't want to lose the respect of being a programmer, because I might if every language becomes like Visual Basic.
There's *respect* ? Seriously, I'm surprised that you don't like VB, it comes from microsoft, after all.
Martin Marvinski wrote:
This is a dangerous trend because if it continues the only real programmers will be at MS and everyone else will be VB losers.
Watch out for Paul when you say things like that....
your statement is not quite true for two reasons.
1/ There will always be jobs outside the Microsoft domain.
2/ Just because the tools available allow sloppy programming does not mean all programmers will be sloppy. I may pay a performance hit for garbage collection, but that does not mean that moving to a GC language will make my programs suck, or somehow suck the life force from me. The percentage of people who call themselves programmers and have no idea will obviously rise, but there will still be good programmers, regardless of where they work.
I don't believe it is impossible to write good programs in VB. I do believe it is not a terribly good tool and I would certainly never seek to use it, but that does not mean that every VB programmer is an idiot, only that the language fails to punish idiocy the way C++ does.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Martin Marvinski wrote:
I think this is a bad trend. When the tools start hiding how things actually work you always lose control.
Well, they are hidden only from programmers who dont mind them being hidden. For those who want to explore, know more and find out how things actually work, there are always ways to do that.
I mean MFC hides a lot of stuff from programmers. But the good ones dig in and figure out what actually happens. The same for .NET. I bet we'll soon be having books on .NET internals and MSIL
Nish
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
