Why .NET?
-
Yep, but you sure can tell when a naive VB programmer is writing in .NET.. Ryan
"Michael Moore and Mel Gibson are the same person, except for a few sit-ups. Moore thought his cheesy political blooper reel was going to tell people how to vote. Mel thought that his little gay SM movie about his imaginary friend was going to help him get to heaven." - Penn Jillette
-
Jeremy Falcon wrote:
And yet nobody said that about Java or classic VB. Both of which were capable of delivering products faster
Both equally shite as languages ;P Blogless
norm.net wrote:
Both equally shite as languages
One could argue the same thing of .NET. :) Jeremy Falcon
-
Yep, but you sure can tell when a naive VB programmer is writing in .NET.. Ryan
"Michael Moore and Mel Gibson are the same person, except for a few sit-ups. Moore thought his cheesy political blooper reel was going to tell people how to vote. Mel thought that his little gay SM movie about his imaginary friend was going to help him get to heaven." - Penn Jillette
That's one thing I always found odd. Most classic VB teachings never really discussed design principles/patterns, and well, it shows. :) Jeremy Falcon
-
norm.net wrote:
Both equally shite as languages
One could argue the same thing of .NET. :) Jeremy Falcon
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
I repeat, there isn't a language good for all. Obviously you cannot write drivers in .NET. Always use the best language and platform for each purpose. .NET is very good for many applications (or part of them), C++ will be always good for OSs, drivers, and so on. For example I have to write and test a complex algorithm in C before porting it to the target platform (it will be run on an embedded device). I'll implement the IO functions in .NET and run the algorithm as a wrapped native DLL to keep the focus on important aspect of the development. If I had to write all the IO functions (anyway they would be thrown away after the testing), I would waste lots of time, without bringing benefits to the projects. ___________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA]
-
fat_boy wrote:
No, perhaps NT4 sp6a tightened up to Military spec might do, but then again, didnt that US Frigate drift around the ocean for a few days while they worked out how to bring the NT system that ran the whole boat bacj up? Perhaps I would just get rid of Windows.
Wow! There goes your pay cheque. Blogless
-
I repeat, there isn't a language good for all. Obviously you cannot write drivers in .NET. Always use the best language and platform for each purpose. .NET is very good for many applications (or part of them), C++ will be always good for OSs, drivers, and so on. For example I have to write and test a complex algorithm in C before porting it to the target platform (it will be run on an embedded device). I'll implement the IO functions in .NET and run the algorithm as a wrapped native DLL to keep the focus on important aspect of the development. If I had to write all the IO functions (anyway they would be thrown away after the testing), I would waste lots of time, without bringing benefits to the projects. ___________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA]
.Net is good for web based swervices. PERIOD. Just like J2EE. Client side it has no benefit over C++ and one draw back. It is damn slow. BTW, C++ for drivers is a bad idea. It can be done, but there are so maany pitfalls that C is the officially suppported language.
Dario Solera wrote:
embedded device
What embedded devices support .Net? Nunc est bibendum
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
It's a tool, not a religion. Use the tool you feel appropriate for the job, but know how to use all the tools in your toolchest. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
-
.Net is good for web based swervices. PERIOD. Just like J2EE. Client side it has no benefit over C++ and one draw back. It is damn slow. BTW, C++ for drivers is a bad idea. It can be done, but there are so maany pitfalls that C is the officially suppported language.
Dario Solera wrote:
embedded device
What embedded devices support .Net? Nunc est bibendum
fat_boy wrote:
Client side it has no benefit over C++ and one draw back. It is damn slow.
You really need to look into declarative programming. C# is a perfect language for that. The .NET class libraries for XML handling, Databinding, ADO.NET are also far superior to anything in the MFC/C++/WTL world. I've written a lot of desktop business apps that use C#. And I'm far more productive with it, than I ever was in MFC. Michael CP Blog [^] Development Blog [^]
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
Isn't the idea behind a virtual machine to decouple from the physical hardware so the two can change (evolve) independently? '--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
-
.Net is good for web based swervices. PERIOD. Just like J2EE. Client side it has no benefit over C++ and one draw back. It is damn slow. BTW, C++ for drivers is a bad idea. It can be done, but there are so maany pitfalls that C is the officially suppported language.
Dario Solera wrote:
embedded device
What embedded devices support .Net? Nunc est bibendum
fat_boy wrote:
.Net is good for web based swervices. PERIOD. Just like J2EE. Client side it has no benefit over C++ and one draw back. It is damn slow.
I think you're a little wrong. .NET is good for many other things, anyway it's not that slow, IMHO.
fat_boy wrote:
BTW, C++ for drivers is a bad idea. It can be done, but there are so maany pitfalls that C is the officially suppported language.
Never developed a driver... so I take your statement as correct. :)
fat_boy wrote:
What embedded devices support .Net?
No one, I think. In fact the device I'm working on supports only C/C++ and Assembler (Atmel Diopsis 740, ARM RISC processor + DSP). I use .NET only to "simulate" the IO ports on the PC: on the PC the Input will be a Wave file and the Output a MP3 file, but on the device the Input is an array of bytes from 2 ADC and the Output is a stream of bytes (containing mp3 frames) sent to the USB port output buffer. ___________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA]
-
norm.net wrote:
Wow! There goes your pay cheque
For mission critical I would never considder windows, would you? Nunc est bibendum
-
It's a tool, not a religion. Use the tool you feel appropriate for the job, but know how to use all the tools in your toolchest. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
Exactly what I think. ;) ___________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA]
-
fat_boy wrote:
.Net is good for web based swervices. PERIOD. Just like J2EE. Client side it has no benefit over C++ and one draw back. It is damn slow.
I think you're a little wrong. .NET is good for many other things, anyway it's not that slow, IMHO.
fat_boy wrote:
BTW, C++ for drivers is a bad idea. It can be done, but there are so maany pitfalls that C is the officially suppported language.
Never developed a driver... so I take your statement as correct. :)
fat_boy wrote:
What embedded devices support .Net?
No one, I think. In fact the device I'm working on supports only C/C++ and Assembler (Atmel Diopsis 740, ARM RISC processor + DSP). I use .NET only to "simulate" the IO ports on the PC: on the PC the Input will be a Wave file and the Output a MP3 file, but on the device the Input is an array of bytes from 2 ADC and the Output is a stream of bytes (containing mp3 frames) sent to the USB port output buffer. ___________________________________ Tozzi is right: Gaia is getting rid of us. My Blog [ITA]
Dario Solera wrote:
I think you're a little wrong. .NET is good for many other things, anyway it's not that slow, IMHO
They probably have improved, added support for things like DBs etc, so I conceede there could be some benefit over MFC. I am generalising. Regarding Embedded, I was wondering if you were running NT or XP embedded on a device. Nunc est bibendum
-
fat_boy wrote:
Client side it has no benefit over C++ and one draw back. It is damn slow.
You really need to look into declarative programming. C# is a perfect language for that. The .NET class libraries for XML handling, Databinding, ADO.NET are also far superior to anything in the MFC/C++/WTL world. I've written a lot of desktop business apps that use C#. And I'm far more productive with it, than I ever was in MFC. Michael CP Blog [^] Development Blog [^]
-
OK, I suppose improovements have been made over MFC support for those, but it is still alot slower than native code. And a lot bigger too. Nunc est bibendum
fat_boy wrote:
but it is still alot slower than native code.
I notice a small speed decrease, but non of my users have.
fat_boy wrote:
And a lot bigger too.
Once the framework is installed, the actual .EXE and dll's are a lot smaller. Michael CP Blog [^] Development Blog [^]
-
Simon Hofverberg wrote:
and to be honest I must admit that I really prefer non-VM code.
but why do you prefer it? Michael CP Blog [^] Development Blog [^]
Michael P Butler wrote:
but why do you prefer it?
I guess the short answer is flexibility and control. Sure: for ultimate flexibility and control you should always use assembler :-D There's always a trade-off between flexibility + control on the one hand and ease-of-use on the other hand. But come to think of it, what I don't like about .NET (and Java) is not that it's a VM (after all, the Win32 API is kind-of a VM too, it's only the kernel that isn't). What I don't like is the garbage collection. It's the flexibility and control of pointers that make me reluctant to use .NET. /Simon This is not a signature.
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
Reasons to use .NET
- Increased security (both in applications having less chance to cause havoc, and malicous users having less chance of effecting buffer overflow attacks) since it's built into the framework
- reduced bugs and increased reliability through a managed environment
- higher productivity through a better architected language, better tools (reflection allows better intellisense, debugging etc), and a single Base Class Library for all languages
- Inter-language operabililty and a common programming model
- A wicked-cool component model
- No more DLL hell
- XCopy deployment (sometimes)
- The inevitable march towards XAML and the convergence of Web and desktop development
That's off the top of my head. I'm sure I've missed a couple. However, there's no valid argument (yet) to say everyone should move from Win32 to .NET. .NET simply isn't suitable for all tasks (OS development, drivers, high-perf applications). As always, choose the right tool for the job. cheers, Chris Maunder
CodeProject.com : C++ MVP
-
It's a tool, not a religion. Use the tool you feel appropriate for the job, but know how to use all the tools in your toolchest. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
Marc Clifton wrote:
It's a tool, not a religion.
Couldn't agree more.
Marc Clifton wrote:
Use the tool you feel appropriate for the job, but know how to use all the tools in your toolchest.
I completely agree on that one as well. But ... why can't I have the cake and eat it too? Why can't MS continue to improve their native tools as well? It sure isn't for lack of resources - indeed it would cost them very little to get something like the .NET framework (the classes of it) running in native C++. /Simon This is not a signature.