|
Sure, buy a faster machine to get .NET programs running almost as fast as C++ compiled applications on slower machines... oh, and don't forget to double that RAM (because that managed code is hungry).
Imagine that MS ever came around to rewriting Word 2003 in C#, what kind of machine would we be talking about here? (of course this is strictly hypothetical)
Do you really thing getting more powerful machines so you can do as much and as smoothly as do now is positive evolution?
Miguel Hasse
|
|
|
|
|
|
Are you certain you've tried to run .NET applications... I have two main work machines a 2.6Ghz with 1GB RAM and a 2.8Ghz with 512Mb... Small .NET applications don't run only these machines they walk and eat RAM.
MIguel HAsse
|
|
|
|
|
|
MicroSoft is trying to slow down the speed of PCs with their newer OSs developed by new languages. It reminds me in the old Dos days, 80386 PCs with dos platform and 640kb ram or several MGs runs dos program much faster than 686 with Win9x, Win2000/XP with 256/512 MG Rams.
I by chance have had the opportunity to support such a program with customers using OS from Dos to WinXP. The program gets slower and slower with faster and faster PC, newer and newer platform. I didn't and I don't want to complain about M$ which gives me opp to earn my bread on table. In fact M$ has created alot of working opportunities for millions people, eg. VB, VC and now it is C#. I will put my hands on C# some days in the future just in case it disappears too soon.
Just a kidding;P, don't take it too serious .
Regards,
Ke
|
|
|
|
|
Alvaro Mendez wrote:
But if you're so concerned about execution speed, by all means write your programs in Assembly. I hear it's super duper fast.
Only if you are very, VERY good in assembly programming, which I am not. Modern C++ compilers are damn good these days, and I don't think I would be able to write any non-trivial application in assembly that would outperform the same application I would write in C or C++.
However, I agree that this argument about "slow C# vs fast C++" is 
|
|
|
|
|
I think the real problem with using is that it is only truly helpful in situations where object lifetime is extremely simple. This method of resource cleanup falls apart when a resource is used more than once ( i.e. we maintain a reference to this resource for later use ). The object that holds a reference to an IDisposable can itself implement IDisposable but this also assumes that this object has simple lifetime patterns. And what about resources whose lifetimes don't match those of their owner? What about collections? Do they know anything about IDisposable? Do I need to keep track of everything I throw into a collection and never reference again? How would I even know when to reclaim those resources that are just sitting around, cached, waiting to be used again? I know there are ways around these problems but all of those solutions highlight the inherent disconnect between the purely managed world ( where the CLR manages everything for us ) and the world where I have to keep track of the lifetimes of my objects in very detailed ways. Coming from the C++ world where this is all explicit makes the problem here seem like a flaw of architecture, but I think that the real problem is that C++ programmers are lazy ( I'm not excluding myself from this ). Scoped resource reclamation is no longer possible and we have to actually think about disposing of our resources instead of allowing the compiler to handle it for us. It took me a while to figure out why I am a little uneasy with .Net, but it turns out that it has everything to do with managing details I've never had to manage before. I know that I had to call delete or free or RegCloseKey before but that was all right because the entire language is structured that way and its fairly easy to see where you are not releasing resources, but in the CLR, where the world is very dynamic and where I never have to think about reclamation, IDisposable and using look like hacks elevated to the level of infrastructure. Well, maybe its not quite that bad 
-Lonnie
|
|
|
|
|
|
It allows me greater productivity, then c++ ever. Some projects show even 50% decrease in lines of code.
Sorry, I am not a student to code for fun, I code for money (mostly at least) so les code -> more money
|
|
|
|
|
Never a true word my friend, I couldn't of put it any better.
|
|
|
|
|
In school I worked on an application. This application was implemented in C#. The .NET nightmare started after a few days when I discovered that I couldn't use the pre-processor.
Short after that discovery, I figured that everything I love C++ for is gone in C#. Beside that, All the things I hate Java for should be the power of C#.
I guess that I enjoy freedom and small/fast apps rather than rapid development and dirty programming.
My opinion on .NET/repid development is:
A rapid developer is a bad developer.
Now that the project is done, I stick to C++.
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
Bob Stanneveld wrote:
A rapid developer is a bad developer.
I don't know about that. IMO, that a rapid developer is either a "bad" developer, or a really good developer.
Aaron Eldreth
TheCollective4.com
My Articles
While much is too strange to be believed,
Nothing is too strange to have happened.
- T. Hardy
|
|
|
|
|
Development comes with fast fevelopment time, huge distributables and slow programs.
I prefer small and efficient programs. If this comes with more development time, so be it. My name stands for quality instead of quantity..
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
Programs written in C# can be small and efficient, and in many cases, every bit as fast as an equivalent C++ program, but with fewer security risks and fewer bugs and memory leaks.
You have a point about the distributable size, but the advantages of .NET, and C# in particular, far outweigh this minor issue.
My guess is that you never really gave C# the chance that it deserved. You can't code in C# in the same way that you would in C++. It's something new you have learn and get used to. Just because the preprocessor in C# won't let you do what you could with C++'s doesn't mean that it is inferior. Instead, there is simply other (usually far more elegant) ways of doing the task.
That said, there are plenty of reasons to stick with C++. It's always a case of what is the best tool for the job. But these days, C# is more and more often turning out to be that best tool.
|
|
|
|
|
Bob Stanneveld wrote:
The .NET nightmare started after a few days when I discovered that I couldn't use the pre-processor.
A good C++ developer shouldn't be using any preprocessor magic anyway. It's not typesafe and in many cases not even portable.
Granted I don't use .NET, but my reasoning is that it doesn't bring anything to the table that would benefit desktop or embedded (as in RTOS VxWorks stuff, not WinCE) development. I've seen very clean elegant C# code from many people here on CP, and for the right job, .NET very well may be the right tool. I guess I don't know what my point is other than to let you know your drivel about .NET wasn't very well substantiated by your empty whining.
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
Nitron wrote:
A good C++ developer shouldn't be using any preprocessor magic anyway. It's not typesafe and in many cases not even portable.
I don't use all the pre-processor magic, I just use the simple #ifdef and related for building different releases.
IMO this functionality should be available for every language, but this will newver happen even is there's world peace..
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
Bob Stanneveld wrote:
I don't use all the pre-processor magic, I just use the simple #ifdef and related for building different releases.
Actually, all the current .NET languages have #ifdefs and custom build configurations...
Yes, even I am blogging now!
|
|
|
|
|
Bob Stanneveld wrote:
I just use the simple #ifdef and related for building different releases.
IMO this functionality should be available for every language, but this will newver happen even is there's world peace..
I guess the whole Congo thing is a misunderstanding[^]?
--
Russell Morris
"So, broccoli, mother says you're good for me... but I'm afraid I'm no good for you!" - Stewy
|
|
|
|
|
Thats all I need concerning PP-directives...
Guess I'll have to give C# another chance (someday)
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
Bob Stanneveld wrote:
My opinion on .NET/repid development is:
A rapid developer is a bad developer.
That offends me. Just because someone writes code quickly doesn't mean that they write bad code. One can be a bad developer in any programming language, but just because they use a language that you dont like doesn't mean they are a bad developer.
|
|
|
|
|
Kyle Edwards wrote:
That offends me. Just because someone writes code quickly doesn't mean that they write bad code. One can be a bad developer in any programming language, but just because they use a language that you dont like doesn't mean they are a bad developer.
True, but since rapid developers often choose quantity over quality (in terms of runtime speed and package size). This choice may not be up to the avarage developer, but I think this is a bad choice.
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
I think you misunderstood when you read up on RAD. Perhaps you should read it again. The definition is not a developer slinging code as fast as he can go with no regard to quality which seems to be what you think it is.
Also, you said you wrote your C# application in school. What qualifies you to make the statement "rapid developers often choose quantity over quality"?
|
|
|
|
|
my thoughs are these:
a BAD PROGRAMMER is he who picks his tools according to HIS _liking_, not according to a project's requirements. Sounds like you hate c# just like I hate eggplants... I never tried the thing, but I can't stand even looking at it.
People here would finish 3 projects in C# while you're creating header files for the first.
$$$$
Grow up.
|
|
|
|
|
Slash74 wrote:
Also, you said you wrote your C# application in school. What qualifies you to make the statement "rapid developers often choose quantity over quality"?
Last year I did an internship at a company which developes .NET applications. All the senior programmers in the department I worked in, were complaining about .NET. Not because you can create an app just like that, but because the custumor keeps complaining about how big an slow the apps become.
Back in the days of C++, custumors were complaining about the long development time.
Now I ask you: which do you prefer, custumers who complain about the quality of your product or custumers who complain about the time it took you developing it?
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
Bob Stanneveld wrote:
Now I ask you: which do you prefer, custumers who complain about the quality of your product or custumers who complain about the time it took you developing it?
So my question to you: do you prefer working at a software company that stays in business because it provides working systems at a reasonable price, or do you prefer working at a software company that goes out of business because all development work takes so long and is so expensive?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
