Printable View
C# and the rest the VM languages have an incredibly high overhead when compared to native win programiing.
Why would anyone choose to go this route?
I have no choice but after comparing the implementation of a simple rank/hash lookup in c#, then comparing the same code to C I am underwhelmed.
Well...I do not want to get in too deep here since I usually avoid such discussions. There is no thing like the best programming language etc. The same applies here...one reason why you would go with that is simply platform independency. The produced intermediate code can be compiled and run on every platform which supports the .NET framework. There are other reasons differently seen by anybody else...however, speed is not the only criteria which is important...what if the C developer needs fifth as long as the C# developer for the implementation? The developing costs will increase...and the gain you will have by being faster might not worth it.
Nevertheless, you basically choose a language based on the project that needs to be done. This includes requirements of your customer, the knowledge of your staff, the timeframe you have etc. If you only look at the speed difference...then the whole world would still program in assembly... :cool:
I agree 100% :)Quote:
Originally posted by Andreas Masur
Nevertheless, you basically choose a language based on the project that needs to be done. This includes requirements of your customer, the knowledge of your staff, the timeframe you have etc. If you only look at the speed difference...then the whole world would still program in assembly... :cool:
I'm unconvinced about .NET's usefulness for commercial programs (try running a decompiler on the .NET library itself sometime), but we're looking at it for in-house tools. Being able to literally slap together a quick program that's used for debugging is immensely useful, especially today when alot of companies don't have people that can just do tool support. The amount you can do without knowing alot of MFC or WinAPI work is the strong point.
maybe the world is moving away from 'deep' programming in favour of a new generation of languages.
i did C++ at uni and wasn't a microsoft fan at all when i graduated. i did more of a DB degree but landed a job as a developer, first in C++, then delphi and PHP, then C# and i must admit i do like it. we use c# for a three tier multi application system that has auto updating and runs fine on the lan and c# suits our needs very well.
in terms of speed vs native calls i wouldn't be able to comment but i do feel that c# is aimed primarily at RAD and therefore, if enough people move, it may signal a fundamental shift away from programmers going as low as that.
i don't know if this is a good thing, there is a developer in our team who doesn't know what a class is and can't write a query that joins two tables and yet he can survive as a developer without too many problems ...
maybe c# will open a lot of doors for a lot more people and that causes some people to feel unconfortable ...
Maybe.. but there will always be room for low level programming. From what I've heard, PC applications are in the minority when you look at actual programs. Most code runs on embedded systems - remote controls, cell phones, network equipment, etc. A few years ago all the Java people were raving about how Java would be the new language used everywhere. That didn't happen because running Java on many systems would require a processor that cost 10x as much as one needed to run C code.
The way I see it, there's no "one" language - and anyone who says there is doesn't know what they're talking about. C# seems excellent for rapid prototyping on Windows systems. Java still seems good for web pages. C and Assembly will still be used for embedded systems with little or no ram and small processors. Perl will still be used for string processing scripts.
i would agree except that C# is more than a prototyping language and the .net compact framework does great stuff on mobile devices etc.
and of course the world moves on, if you don't move with it then you're soon left behind ...
A lot of great replies here, thank you for all of them P
"choose a language based on the project that needs to be done"
Is probably the most succinct, but until we rise up and banish the managers of this world..... :P they choose the technology.
C# has all the features i detested in java :) and a few more, but is much more robust as long as you are doing run of the mill coding.
now that I have moved on from functionality to presentation, and i am hurdling the limitations of its GUI components. I am finding that most of my code starts with:
[DllImport("shell32.dll")]
and other OS DLLs mainly because they seem to have forgotten about a coders need to be able to modify windows code :(
I suspect in a few more revisions of .Net we will see a more more friendly API.. we can only hope :P
When I get time i will benchmark my rank/hash functions from native c++ to C#, and post the results. A little tweaking in the .Net core and i would be happy :)
Oh, and expect a lot more posts from this c# newbie :)
"maybe the world is moving away from 'deep' programming in favour of a new generation of languages."
Just thought i might reply to this, until they adjust the .Net API there will be only one way to do certain things, and that is the old way.
This is probably one of the largest hinderances to moving to C# is that the only way of doing certain things is by understanding and using Windows API, which does in a sense defeat the purpose of having a completely non language specific interoperable VM.
So Don't forget about subclassing windows for now :)
I'm confused.. what could I possible want to do in C# that I would need to subclass??Quote:
Originally posted by Katrinz This is probably one of the largest hinderances to moving to C# is that the only way of doing certain things is by understanding and using Windows API, which does in a sense defeat the purpose of having a completely non language specific interoperable VM.
So Don't forget about subclassing windows for now :)
In my opinion, if I were going to do real system level programming I would not use C#.
Jim
Well, because C# has many things that are ready to use for you. It's easy to learn. And still fast :)
I think you should give it a try :D
Oh, I am already giving it a try! :DQuote:
Originally posted by WillemM
Well, because C# has many things that are ready to use for you. It's easy to learn. And still fast :)
I think you should give it a try :D
My company is building a new client application all in C# and we plan to implement the auto update feature. Much cheaper than setting up all the Java servers we would have had to use if we went with a Java app. And I agree that C# is easy to learn and fun! I haven't had to pull my hair out like I used to do with MFC. :D
Jim
your not bald yet? :P
I am working for an automotive company and I do the tool support. Of course that using C# is the best way to achive good results in little time and as the others say it quite fun. But working here it shows me what the others programmers are doing for car's ECU's (Electronic Control Unit). For the ones that are not familiar whit automotive I can say than now even the spark for a car's spark plug is given by a software. This you will not do in C# now and I think that you will not do it in c# in the near future even.
I do use C# for automation of several things in my room. For example: I have a Microcontroller connected on a comport of my pc. I control this one with my C# software.
Ok, I agree hardware control asks a little more from the programmer then normally.
Of course, once you work out and profile that a part of your code is too slow and you're pretty sure your algorith is the fastest, then one should recode the module in C or assembler and link to that code in the time saved by using C# over writing the whole project in assembler. :)
That would be embedded software - I'd wager there's more embedded software in the world than PC software. It's got a whole other set of requirements - you don't have a gig of ram and a 30 bazillion GHz processor to do fun stuff with. That's why C will be a very long time in dying. It's got a relatively clear and popular syntax, it's reasonably efficient, it allows low-level memory manipulation, and still allows for good OOP-style design (although without language support). Remember - the right language for the right job!Quote:
Originally posted by vma
I am working for an automotive company and I do the tool support. Of course that using C# is the best way to achive good results in little time and as the others say it quite fun. But working here it shows me what the others programmers are doing for car's ECU's (Electronic Control Unit). For the ones that are not familiar whit automotive I can say than now even the spark for a car's spark plug is given by a software. This you will not do in C# now and I think that you will not do it in c# in the near future even.
indeed - if i was feeling british i'd say 'here here !'.
but with Bush being here ....
:(
When you benchmark, make sure you do two separate benchmarks on your C# code (or any other .NET code). Benchmark the code running it the first time, then benchmark it separately after having ran all of the code once. With the JITs in the runtimes, you should only take a real performance hit the first time code is ran. (JIT=Just in Time compiler)Quote:
When I get time i will benchmark my rank/hash functions from native c++ to C#, and post the results. A little tweaking in the .Net core and i would be happy
Just a thought.
On another note, someone mentioned decompiling. If you value your source/logic, then you will obfusicate any publicly released .NET programs.
Brad!