|
What are the real benefits of Managed Code?
I heard this buzz phrase a lot in respect to .net: "Managed Code"
What is it?
What's the benefit.
My google search revealed that MC gives you Garbage collection.
Beyond that, I don't see the practical benefits.(I'm sure they're there, I'd just like to know WHAT they are.)
"Code that is executed by the CLR. Managed code provides information (i.e., metadata) to allow the CLR to locate methods encoded in assembly modules, store and retrieve security information, handle exceptions, and walk the program stack. Managed code can access both managed data and unmanaged data"
Mr. Analogy
Thursday, April 29, 2004
I believe MC gives the end user the benefit of perhaps just a tad bit more stability because you might consider it a Virtual Machine? or not?
Garbage collection is present in many other non MC environments.
Basically MC gives Microsoft more benefit than it does any other group. It is a lot of hype. Install this 20 MB Virtual Machine that runs "Managed Code" and your application will be better off? Nah. Install .NET so we can make a profit on something new? Yup.
Win32 or some form of the API will be around for a heck of a long time. At least until drastic hardware changes take place or some other paradigm comes up. You will always have access to this API. This is because your abstractions are not my abstractions.
anon
Thursday, April 29, 2004
Managed Code is a marketing buzzword. The CLR and CTL are real things though behind "Managed Code" that provide real benefits to developers. Like being able to call my "Managed" C++ routine from VB.Net or Python.Net or Pascal.Net or whatever in the hell fells like using it and vice versa.
Elephant
Thursday, April 29, 2004
Running off the .NET CLR is also supposed to give added security benefits:
http://msdn.microsoft.com/msdnmag/issues/02/06/rich/default.aspx
Herbert Sitz
Thursday, April 29, 2004
Managed Code and Managed Data bring a lot to the table. It really means that there is whole crapload of stuff that, if coding in C++ say, would be on the developers plate.
For example, if write managed code you won't have to bounds check your arrays when you loop through them. There are all kinds of things that managed code (which is what the Java VM is as well) gives you so that you can develop your application without worrying about the low-level details.
This can prevent things like Buffer Overruns, which can cause major security headaches.
There are also benefits to managed code like type-safety. I can't think of others right now, but it makes developing a whole crapload easier.
Gp
Thursday, April 29, 2004
There's a brief comparison of using (not of writing) managed versus unmanaged code at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcongeneralconsiderations.asp
Christopher Wells
Thursday, April 29, 2004
"Install this 20 MB Virtual Machine that runs "Managed Code" and your application will be better off? Nah."
Some of the ways it can make your application better are:
1. Bounds checking at run-time.
2. Improved security.
3. Garbage collection
4. Large collection of existing functionality built in to the CLR, reducing the need to "roll your own" stuff.
"Install .NET so we can make a profit on something new? Yup."
How exactly are you figuring MS is making a profit directly from the .NET runtime?
Mark Hoffman
Thursday, April 29, 2004
To play devil's advocate...
"1. Bounds checking at run-time."
Nothing, except for a performance penalty, is stopping native code from stringent bounded techniques (such as a collection class) rather than native arrays, and of course there are many solutions of that type.
On a more fundamental level I find it frightening when people say "You no longer need to worry about..." -- Oh yeah, the code might has a logical fault that deletes the wrong file and provides access to the wrong thing because of the wrong declarative security...but you've got no worries about those array bounds!
"2. Improved security."
It's debateable as to whether there are more security options achieving the same level of security, or if it is a truly an improved level of security.
"3. Garbage collection"
Garbage collection is an unwiedly solution looking for a problem -- it has been _years_ since memory leaks have been a problem given the wide availability of excellent profiling/memory leak detection tools. So now we have a system that frees objects when it gets around to it (so you now have side effect issues like abandoned ADO.NET connection objects hogging connections), in a unpredictable manner. I personally prefer standard COM style reference counting, rather than the "make it all one giant short term memory leak" technique of GC. People can pimp GC all they want, but I've yet to see a credible real-world benefit beyond "making lemonade out of lemons".
"4. Large collection of existing functionality built in to the CLR, reducing the need to "roll your own" stuff."
There is some great functionality in the framework. Indeed for several COM clients, with the framework installed, I've basically just exposed .NET functionality via a CCW and it works great for them.
Dennis Forbes
Thursday, April 29, 2004
As someone who had done C++ for a number of years, I was shocked at the increase in productivity by going to managed code. Individually, the benefits don't seem that great, but on the whole, they're tremendous. Going back and doing maintenance on our C++ code base seems like COBOL.
As someone who thinks in terms of memory spaces, pointers, and execution cycles, the idea of managed code was troubling at first. I overcame this by learning about the internals of garbage collection, typing, intermediate language, etc. It's still bits and bytes, but I can get a whole lot more done. Microsoft's CLR may seem like this black box of bloated code, but once you see how the memory is laid out, you'll see there isn't a whole lot to it.
For most programs, execution time is spent calling APIs, not developer code. The performance of the .NET API can be disappointing in places, but the overall performance of managed code is actually quite good.
I have a certain amount of nostaglia about C and ASM and the idea that you could almost feel the transistors flip between states. That was cool. Sitting down and whipping up a program in a day that would've been a week with MFC/Win32, that's cool also, albeit in a different way.
Bill Carlson
Thursday, April 29, 2004
"The performance of the .NET API can be disappointing in places, but the overall performance of managed code is actually quite good."
That's because a large part of the Framework isn't managed code, but is instead just a stub to native code.
Dennis Forbes
Thursday, April 29, 2004
>> "How exactly are you figuring MS is making a profit directly from the .NET runtime?"
I don't mean MS is making money directly off of the runtime.
I'm saying MS is making something new that in all reality doesn't add much benefit to and is not that much different than the likes of VB or Delphi. And if you're making something new just because you can... well what's the point of that? To make money of course.
It's basically so they have something to give to the marketing guys... We have this new Virtual Machine called .NET it's revolutionary! Not!
With the power that MS wields they can eventually force this thing onto everyones computer, like it or not. .NET is not needed but we're getting it anyway because of the bottom line, money. And you can't make money by releasing service packs for VB.
.NET is a marketing scheme designed to grow the Microsoft Company.
I'm not anti-MS btw.
anon
Thursday, April 29, 2004
Dennis,
I agree with your points. Given unlimited resources, unmanaged code has some advantages. The problem is that most teams, by definition, are not composed of A-list developers.
Will managed code make a bad developer into a good one? No, but it will make a bad programmer into a mediocre one. Or at least less dangerous.
There's a lot of elitism that goes on in JOS, but I don't think it's a stretch to say that there's a substantial portion of our peers that don't reference count very well and who don't communicate well enough to know who's supposed to free the pointer and when. There's time wasted communicating changes to header files, etc.
Whenever my mom sees me getting take out, I get the "you know, you could make that at home" lecture. When I want something in particular to eat or am trying to impress a date, I'll cook at home. Managed code is kind of like getting take out.
Bill Carlson
Thursday, April 29, 2004
anon,
Managed code is a tool that some people find very useful for getting their projects done quickly and with fewer bugs. Whether it's revolutionary or not is irrelevant.
I have a lot of problems with how .NET was marketed. MS didn't really tell people what .NET was until about 9 months after it was released. All we heard was the usual "your data everywhere empowering you" crap.
I don't really understand the anti-.NET bias. Obviously, there's nothing new under the sun; every program is possible using ASM. The WordPerfect 5.1 for DOS people thought Winword users were weenies for not using markup tags. That's fine.
I like .NET because it's allowed my team to be ahead of schedule enough that I can take time to write this message. We create vertical market accounting software, not dissimilar to the bulk of programming work being done today. .NET may not be good for what you're doing, but it has the potential to help a lot of companies develop faster with reduced bug count.
Bill Carlson
Thursday, April 29, 2004
"Managed code is kind of like getting take out."
For some reason, I really love this statement!
ken
Thursday, April 29, 2004
I'm not anti .NET either. I'm simply pointing out that nothing new has been accomplished. Contrary to your examples where something new had been accomplished. There is a world of different between a GUI and a text based interface.
How does .NET allow you to save time developing your applications over say VB? What new thing about .NET saves you time? I'm sure all arguments to that would be weak.
.NET is a money maker pure and simple.
If .NET saves you so much time that you can make posts on this board then someone obviously isn't doing their job and perhaps someone should lose their job given all of the wasted time?
anon
Thursday, April 29, 2004
"I don't really understand the anti-.NET bias" ...
It's the fact that
1) Your program is no longer executed by the CPU, but by a Microsoft software product (CLR) that will likely bloat over time (as MFC did, or the VB runtime) and have its own instabilities and critical security patches. (It's the lack of control over this -- your stable product suddenly becomes unstable with some patch).
2) Your software is forever after locked into a Microsoft OS. You cannot port to Unix, and you cannot put it on an embedded device or if that's where your market and your customers go, or re-use any of your code with products you might have on those platforms.
Those are my main objections, but I admit the testimonials about productivity sound convincing...
Ron
Thursday, April 29, 2004
> You cannot port to Unix ...
Perhaps you can write your .NET code in "managed C++" (instead of C# or VB.NET).
> testimonials about productivity sound convincing
So, another possibility is to treat your .NET code as a RAD prototype: rapidly develop your application as a C# class library, and later recode it as C++ when you want to port to Unix or an embedded device (admitting that, usually, more work has gone into the design of your application than will go into recoding a port of it).
> What's the benefit?
Better than C++ because the .NET framework is a saner class library than MFC.
I can (in the sense that "I would know how to") write C++ so that everything is garbage-collection and bounds-checked ... but with C#, the language does that for me.
And, better than VB because ...
Christopher Wells
Thursday, April 29, 2004
Porting a "managed C++" app to an "unmanaged" C++ platform sounds like you'd find a bunch of errors and overruns the CLR used to take care of for you (and you would have caught had you known the first time).
"And better than VB because..."
I guess it isn't! So why didn't everybody move to VB eight years ago? (I'm not from a VB shop and am actually curious... what were the downsides back then, and wouldn't they be the same with .NET?)
Ron
Thursday, April 29, 2004
anon,
I know little of VB 6.0, so I can't speak of benefits of upgrading from that platform. I do know that C++ folks such as myself are a demanding, surly lot, that aren't going to "upgrade" if it means they're going to have to give up control. C# is suitable for doing the "heavy lifting".
I find it curious that you insist that my experiences are somehow "wrong". I'm willing to grant that, for what you do, .NET may not be the best choice. I think it would be reasonable for you to admit that managed code has pros and cons and that it's a good solution for some people. The average length of experience of developers at my company is around 15 years. This is a crusty crew. Not one of them misses C++/MFC/Win32. I could enumerate the benefits of managed code here/Visual Studio here, but you can find those anywhere.
Ron,
You make valid points. It is worrisome that the CLR may become bloated. Unfortunately, this is the nature of large scale APIs. Look at how J2EE, VB, Win32, etc. have grown. .NET will likely be no different. It's a question of alternatives. In our industry, customers demand rich, client-side UI. We have to hitch our wagon to some horse to provide this; it may as well be .NET.
OS lock-in isn't an issue for many companies. Most of the client machines out there are running Windows. This isn't likely to change rapidly. Linux is pretty cool, but there's a general expectation that apps should be free and/or open source. Hopefully this will change. Our products have a lifetime of 7-10 years. We're willing to bet that Windows will remain a viable platform for that period of time.
My experience has been that a lot of energy is spent on multi-platform development where the end product is only ever run on one platform. It's like database lock-in. You can use ANSI SQL, but it's just too tempting to use that vendor specific syntax, especially when you're behind schedule. All things being equal, cross platform is best, but unfortunately it takes longer and sometimes the end result lacks features. Hopefully, either Java will mature enough to solve this problem or the MS CLR will fill the void eventually.
Bill Carlson
Thursday, April 29, 2004
Bill,
I'm a C++ and VB person myself. I'm saying that .NET, while providing little to no advantage over VB and Delphi, is simply the next stage for Microsoft to build on so that they can continue their revenue stream. Understand?
If you had switched from C++ to VB you would have noticed the same productivity gains as going from C++ to .NET.
Hey, I like .NET and all of it's languages and have used them in the past.
Now why didn't Microsoft create a VB 7 instead of a whole new platform? Because creating a new platform creates higher revenue in the long run. Now you have other companies that feel a need to develop for this new platform. You have Microsofts own products that can now be "ported" to .NET. Microsoft Office .NET for example. Not that these applications would really be ported but putting the .NET label on something sends a message to the naive and uninformed.
.NET is a new name for old things. I personally have not seen any convincing arguments that .NET is more productive than VB or Delphi.
anon
Thursday, April 29, 2004
Garbage collection alone is probably justification to move some projects to Managed Code.
Dan Maas
Thursday, April 29, 2004
Managed Code is a strategic weapon. It means Microsoft arbitrates access to the machine, and thus can enforce application security, eliminating viruses and similar stuff.
Before too long, Microsoft will market this feature to corporate users and then start a process where corporations only run Managed applications. It will be a big kick against Linux too.
Mr Helpful
Thursday, April 29, 2004
Garbage collection? How often do apps run out of RAM anymore due to memory fragmentation?!
Rick
Thursday, April 29, 2004
"I'm saying that .NET, while providing little to no advantage over VB and Delphi"
Deciding whether or not something provides an "advantage" over another product is largely dependent on the context in which you are using it.
My clients are MS centric corporate shops: VB/ASP/SQL type stuff. .NET gives them a tremendous productivity boost over development VB 6.0 and ASP 3.0. No more tortured OOP in VB, better exception handling, loads of built-in code in the Base Class Libraries, easier ability to perform unit testing, and a much, much improved development environment for ASP.NET.
Yes, yes, I'm sure that anything I can do in C#, there is a techno weenie who will claim that they can do it faster in VB 6.0.
So, for my clients that have been using VB 6.0, moving to .NET has paid big dividends. So, yes, there are advantages.
Mark Hoffman
Thursday, April 29, 2004
"Garbage collection? How often do apps run out of RAM anymore due to memory fragmentation?! "
...I dunno, but I can tell you lots of apps have memory leaks. Which, of course, is the problem that garbage collection aims to solve. Not memory fragmentation.
Memory fragmentation is an issue regardless of whether or not a GC is used. The .NET CLR is design to limit memory fragmentation. Whatever techniques they use, they are likely to be better than some non-existent or home-brewed concotion.
Here's your sign
Thursday, April 29, 2004
I suspect that memory fragmentation on PCs running Windows is, for virtually all programs, purely theoretical :)
Tom
Thursday, April 29, 2004
"I personally have not seen any convincing arguments that .NET is more productive than VB or Delphi. "
Then you are listening. Or don't care to hear it.
The advantages of .NET over VB have been given a zillion times by a wide range of people from a diverse background.
If none of these people's arguments make sense to you, then you are in a very, very unique position.
Nobody is talking about a cost/benefits analysis here. There are plenty of good reasons *not* to move to .NET. But if you are suggesting that there are simply no reasons at all to move to .NET then you've got your head in the sand.
Here's your sign
Thursday, April 29, 2004
"Then you are listening. Or don't care to hear it. "
<sigh>
How about:
"Then you aren't listening. Or don't care to hear it."
Here's your sign
Thursday, April 29, 2004
People, People, People
I in fact state that I use and have used .NET. It's a wonderful environment with many minor improvments. I never stated there weren't any improvements.
My point is that .NET is simply a platform to enhance Microsoft's revenue stream in the long term. Pure and simple. Microsoft could have easily incorpated these improvements in the next version of VB or Borland in the next version of Delphi.
See what I'm saying? New platform = new buzzword = new stuff that does the same thing in a different way = more money.
I'm not anti-MS and I'm not anti-.NET. I do use the stuff.
anon
Thursday, April 29, 2004
Well of course .NET exists to help them make money, whether directly or indirectly. I think the only point that you could try to make here is that it's just old hat dressed up in new clothing. But I would definitely have to disagree with that. There are marked improvements to productivity that come with moving developers to c# and .NET.
Richard Kuo
Thursday, April 29, 2004
All of these comparisons seem to be .net vs. {VB6, C++}:
.net is more productive than C++ (no memory management, etc.), yet is OO and has built in functions already done for you.
I agree with those comparisons. Delphi, too, fits that description: more productive than C++, but is OO and has tons of existing controls (the VCL).
Well, this thread is over. Someone's brought up Delphi. <g>.
Mr. Analogy
Thursday, April 29, 2004
>> 1) Your program is no longer executed by the CPU, but by a Microsoft software product (CLR) that will likely bloat over time (as MFC did, or the VB runtime)
Er... the VB5 and VB6 runtimes are barely 1MB. I don't remember how big the rt was from VB 1-4, but I would hardly call a 1MB rt "bloated", especially with today's hard-disks and Internet connections. A very very small price to pay for very high productivity.
Fred
Thursday, April 29, 2004
>See what I'm saying? New platform = new buzzword = new >stuff that does the same thing in a different way = more >money.
Uuhm, MS is not a non profit organization so it surprices you they are trying to make money out of their products?
someone
Thursday, April 29, 2004
.Net will be good for Microsoft, probably good for big corporate users, but bad for ISV's.
Microsoft will eventually encourage corporate IT departments to ban non-Managed applications, and then will undertake to stop, log and audit all hostile code, which it will be able to do.
.Net will also provide a mechanism by which IT managers, the government or the law enforcement can audit every keystroke, web site lookup, sent message and everything else particular users do, since it all has to go through the Managed Code layer.
So might be a bit scary for privacy freaks. ISV's will be forced to toe the line, which might not be good.
Thursday, April 29, 2004
>> "Uuhm, MS is not a non profit organization so it surprices you they are trying to make money out of their products?"
Doesn't surprise me in the least. In fact it seems perfectly natural.
anon
Thursday, April 29, 2004
"Er... the VB5 and VB6 runtimes are barely 1MB. I don't remember how big the rt was from VB 1-4, but I would hardly call a 1MB rt "bloated","
HOW ABOUT SOME FACTS:
VB 3: about 300k
VB 6: 1 MB (300% increase)
.net : 30+ MB (uncompressed: 3000% increase.
I'd call that EXPONENTIAL bloat.
I agree with the above poster: .net is good for company programmers (internal apps) not so good for ISVs.
My suspicion is that .net programmers may be turned into the equivalent of "sharecroppers" you'll only be able to work on someone else's project (i.e., an internal company app) not have your own software company making your own product.
Although, I do know peope who are, today, writing ISV software in .net some are successful (Eric Sink), others have reported problems. One I spoke to this weekend says they have trouble getting big companies like Exxon to OK the .net runtime. Delays sales by many months, may nix some sales (not sure about this latter point).
Mr. Analogy
Thursday, April 29, 2004
"I have a lot of problems with how .NET was marketed. MS didn't really tell people what .NET was until about 9 months after it was released. All we heard was the usual 'your data everywhere empowering you' crap."
Unfortunately, no one can be told what .NET is. You have to see it for yourself.
Take the 20MB pill
Friday, April 30, 2004
How 'bout cooling down? You were talking about bloated frameworks, and mentionned VB. Going from a 300KB to a 1MB runtime over a 7 year period isn't exactly bloat. I was not talking about .Net.
Fred
Friday, April 30, 2004
I don't understand why there's some kind of assumption that garbage collection is inherently better than manual memory management. Forget about memory leaks; I'm talking simple, raw usability.
Many programmers and their architectures work using a paradigm of "single owner, multiple reference". That means any particular object has one controlling force (usually another object) that can keep that object alive, and when that force lets go, the object is gone. This has nothing to do with garbage collection or no garbage collection, it just has to do with programming in general; when your access to a given object is controlled in this manner, you have a choke point for managing it and that makes everything from interface definitions to debugging/diagnostic efforts easier.
In C++ (and manually-controlled memory environments in general) there are many ways to accomplish this type of single-owner, multiple-reference system, many of them being quite easy to construct, and intuitive to use and debug. In a GC environment though, your options are significantly reduced. The single owner is a logically "strong" reference, and the others are logically "weak", yet in .NET all references are strong by default unless you use the painful non-typesafe System.WeakReference objects.
Unless you use these WeakReference objects, what you have is a system where anyone who refers to an object keeps that object alive. Novice programmers or newcomers to GC environments may think this is a good thing, when infact many times it is not. Once you've run into your Nth bug where an object that should have been destroyed is still around because random referencing object X didn't deliberately null out the reference, you start to realize this isn't all it's cracked up to be. After working with .NET for the better part of a year, I found that memory management actually became HARDER than it was in C++, not easier.
This would be a completely different situation if C# and other .NET languages added a simple keyword "weak" that was an object reference member field/property modifier akin to "static". If I could easily go "weak MyClass MyMemberObject;", I would do so for the vast majority of my object references, reserving the few non-weak ones for those "owner" references that really need to be strong. Of course, such a feature probably wouldn't arrive in .NET for a minimum of a couple years, if ever. In the meantime, I'm forced to stay where I'm actually productive, and right now that's in good ol' C++.
BadgerBadgerBadger
Friday, April 30, 2004
Garbage collection has nothing to do with it. It's strategic. It's how Microsoft will kill Linux (by being able to guarantee that applications don't do anything nasty.)
Friday, April 30, 2004
"VB 6: 1 MB (300% increase)
.net : 30+ MB (uncompressed: 3000% increase.
I'd call that EXPONENTIAL bloat."
That would be relevant if it wasn't for the fact that the .net runtime includes far more functionality than the VB runtime.
There is so much functionality included in .net that isn't in VB: HTTP client code, web service support, TCP/UDP socket code, ADO.NET, XML parsers, XSLT parsers, authentication and encryption code etc, etc. I have already used all this parts of the framework in my .net projects.
The fact that the .net runtime is 30 times the VS runtime is a good thing as it means loads of code that I don't have to write or get external components for.
Sure it would be good if MS provided some way of only distributing the bits of the framework that you needed, but that doesn't take away from how useful all that functionality is.
Andy Norman
Sunday, May 2, 2004
 Recent Topics
Fog Creek Home
| 
