Very interesting article about .NET and it's effects on the industry.
Jeff
The future is already here - it's just not widely distributed yet...
Jeff
The future is already here - it's just not widely distributed yet...
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
What does .NET really mean? 2
- Thread starter MasterRacker
- Start date
In a nutshull:
I've argued this point in other threads...it's always good to see some validation. If I may wax hyperbolic, .Net is a desperate attempt to maintain and further world domination.
Like when you're playing "pull the sock from the dog's mouth"--as you're pulling and swinging him back and forth, at some point he'll let go for just a split second to get a better grip on the saliva-soaked sock. This split second is where Microsoft is right now with .Net.
Is the sock going to be pulled from the frothing mouth, or with the jaws clamp down tighter with a better grip?
--Jim
I've argued this point in other threads...it's always good to see some validation. If I may wax hyperbolic, .Net is a desperate attempt to maintain and further world domination.
Like when you're playing "pull the sock from the dog's mouth"--as you're pulling and swinging him back and forth, at some point he'll let go for just a split second to get a better grip on the saliva-soaked sock. This split second is where Microsoft is right now with .Net.
Is the sock going to be pulled from the frothing mouth, or with the jaws clamp down tighter with a better grip?
--Jim
dilettante
MIS
I suspect they saw the advantages Java offered but got into a bind with Sun over attempts to make a decent Windows-native Java. Visual J++ was an amazing product in many ways if you didn't look at it as a Java implementation.
So basically they stepped back, looked hard at where they had wanted to be with VJ++, took a look at where they wanted to go... and they started from scratch to develop a new software infrastructure.
I don't see it any more nefarious than anything else going on in the industry. The real problem is that Microsoft threw the existing customer base, developers, and Windows application software overboard. We ended up with a hard and thorny discontinuity between Windows-past and .Net-present.
Surprise, surprise! People didn't flock to .Net in droves except for ASP.Net which became tremendously popular. I have to wonder how much of that was due to anything-but-VB types who had rejected classic ASP as tainted.
I find this the most amazing part of .Net's development myself. Important productivity technologies pioneered in the VB ghetto got ported to the .Net world, things the C/C++ patriots sneered at for years. Now of course they'd have you believe they were invented for .Net and never existed before.
So basically they stepped back, looked hard at where they had wanted to be with VJ++, took a look at where they wanted to go... and they started from scratch to develop a new software infrastructure.
I don't see it any more nefarious than anything else going on in the industry. The real problem is that Microsoft threw the existing customer base, developers, and Windows application software overboard. We ended up with a hard and thorny discontinuity between Windows-past and .Net-present.
Surprise, surprise! People didn't flock to .Net in droves except for ASP.Net which became tremendously popular. I have to wonder how much of that was due to anything-but-VB types who had rejected classic ASP as tainted.
I find this the most amazing part of .Net's development myself. Important productivity technologies pioneered in the VB ghetto got ported to the .Net world, things the C/C++ patriots sneered at for years. Now of course they'd have you believe they were invented for .Net and never existed before.
a monolithic runtime that reinvents every wheel you ever needed.
except that its not needed to "make computer work"
George Walkey
Senior Geek in charge
except that its not needed to "make computer work"
George Walkey
Senior Geek in charge
chelseatech
Instructor
I looks like I have a different view from the rest of you folks, but I like .NET
I'm a VB6 developer and have a bunch of utilities I've developed in that language. One of them needed to run as a windows service. So rather than wrap some service code around my VB6 objects, I rewrote it in VB.NET.
Okay, it's a rich object model with a lot to learn. But once you get to grips with it, some of the objects are just so neat to use. It's what VB should have been.
Editor and Publisher of Crystal Clear
I'm a VB6 developer and have a bunch of utilities I've developed in that language. One of them needed to run as a windows service. So rather than wrap some service code around my VB6 objects, I rewrote it in VB.NET.
Okay, it's a rich object model with a lot to learn. But once you get to grips with it, some of the objects are just so neat to use. It's what VB should have been.
Editor and Publisher of Crystal Clear
I do actually like .Net, at least the applicaiton programming portion (The ASP.Net portion could go ... well you know). I think there was an opening for Microsoft to produce the next generation of their programming languages and they decided to follow Java in many ways because that was what it looked like the [development] public wanted. Using C#, or even VB.Net, there are many things that are remarkably similar to Java and various other languages, but whether this was mindless copying or an attempt to reproduce functionality that they believed was respectable, etc is anyone's guess (though I believe it is the second).
The two largest failings I have seen so far are the size of running applications and web forms. I won't go into the web forms issue again as I have covered this in multiple forums already. Suffice it to say that everything that i find hinky with ASP.Net finds it's root in Web Forms, and so far I have not found anything truly good about them, from either a developer or end user standpoint.
Runtime bloat is an issue however. I understand that .Net/Java/Python/etc run in a semi-compiled state but aren't compiled directly to machine code like C/etc (though i could be wrong about Python, can't remember what it is compiled to). In any case, you would expect them to have similar emory requirements for simple tasks. I don't remember the esact numbers anymore, but I once wroite 3 pieces of code (well, two anyways) that simply opened a form (one in each language). I've been meaning to repepat this with C# as I did the original in VB.Net, not sure if there would be a diference.
In any case, VB.Net used something like 16000k of memory for an empty form, Java (Swing I think) used something in the 12000k range, and Python (don't remember what package, Tcl?) used something in the 8000k range (or maybe Java and Python were switched, don't remember). No optimization, nothing but displaying a blank form the same size in every one. In my opinion the bloat associated with .Net is a bit much. Perhaps it should be expected (compare Windows version requirements some tie) but I would really expect it to be more in line with Java or even less since MS should be intimately aware of their own OS's and be able to tie things more tightly to the OS in the Runtime.
-T
The two largest failings I have seen so far are the size of running applications and web forms. I won't go into the web forms issue again as I have covered this in multiple forums already. Suffice it to say that everything that i find hinky with ASP.Net finds it's root in Web Forms, and so far I have not found anything truly good about them, from either a developer or end user standpoint.
Runtime bloat is an issue however. I understand that .Net/Java/Python/etc run in a semi-compiled state but aren't compiled directly to machine code like C/etc (though i could be wrong about Python, can't remember what it is compiled to). In any case, you would expect them to have similar emory requirements for simple tasks. I don't remember the esact numbers anymore, but I once wroite 3 pieces of code (well, two anyways) that simply opened a form (one in each language). I've been meaning to repepat this with C# as I did the original in VB.Net, not sure if there would be a diference.
In any case, VB.Net used something like 16000k of memory for an empty form, Java (Swing I think) used something in the 12000k range, and Python (don't remember what package, Tcl?) used something in the 8000k range (or maybe Java and Python were switched, don't remember). No optimization, nothing but displaying a blank form the same size in every one. In my opinion the bloat associated with .Net is a bit much. Perhaps it should be expected (compare Windows version requirements some tie) but I would really expect it to be more in line with Java or even less since MS should be intimately aware of their own OS's and be able to tie things more tightly to the OS in the Runtime.
-T
I think that comparison of code bloat by opening an empty form could be misleading.
A fairer comparison should include some fairly useful code. This is because adding more objects into those pieces of code could yield significantly different results.
__________________________________________
Try forum1391 for lively discussions
A fairer comparison should include some fairly useful code. This is because adding more objects into those pieces of code could yield significantly different results.
__________________________________________
Try forum1391 for lively discussions
BocaBurger
Vendor
Can you do graphics intensive manipulations in only 256 meg of RAM? What ever happened to all those Amiga developers? Stable, tight code, easy to use, marketing worse the Wordperfect, Corel and Novell put together 
BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!
BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!
-
2
- #13
russellbcopeland
Programmer
I've been doing .Net development (win/web/ntier) for almost 3 years now. Before that I did mainly VB6/5/4/3, ASP, some Perl, C++ and MUMPS. Of course there is the old Quickbasic, Fortran, Pascal and Assembly in my past also.
My experience is that .Net is like any other tool. Very good for some things and terribly bad for others.
As far as the marketplace for develoment, I recently went through a job search in the Atlanta area and pretty much all of the new stuff I could find going on in the VB world was .Net. Sure there is a lot of legacy VB6 code out there but very little new development seems to be being done in VB6 anymore. .Net is the future of VB whether you like it or not. There does seem to be a leaning toward C# though. I personally prefer VB.NET to C#.NET though it is mostly because I am more used to looking at the syntax and structure of VB than C.
Bad stuff:
1)It is bad for making high speed, compact, small bits of code wether you're accessing it from the web or any other means. It is fast to make these things though and a lot of time building something fast is more important than wether it needs 16000K or 8000K to run. Memory is cheaper than developer time and most apps dont get that high of a utilization rate anyway. The bottleneck is more likely to be network bandwith and database server access time.
2)It has bloat issues.
3)There is a steep learning code if you want to take advantage of its good points.
4)Microsoft World Domination
Good Stuff:
1)Ironically the fact that it is more difficult to appear proficient with .Net that VB6 is really a good thing. The code I have seen developed in .Net is generally much better code than most of the legacy VB6 code I have come across. .Net is trimming out a lot of sub-standard developers who really shouldn't be writing code to begin with.
2)It is excellent for building business applications.
3)It is excellent from an enterprise standpoint. You can build highly scaleable enterprose applications with it a whole lot easier than using C++.
4)A good .Net Developer costs less than a good C++ or Java Developer and they're easier to find.
5)Reasonably descent support for XML
6) Web Forms are not the most effecient but web servers are cheap and easy to setup in a farm. It is fairly easy to add a device specific web interface to a .Net application that is written properly.
7) OOP is possible with .Net.. not so much with VB6. You can argue for or against OOP but in the long run, when it comes to complex, maintainable systems it is the only way to go. You just can't manage a complex system without using at least some concepts of OOP.
8) You can always write C++ components and call them if you really have the need for that kind of effeciency in some calculations etc.
9) MOST OF ALL: Once you go .Net and have to go back to VB6 you will realize just how much better .Net really is. It really just makes business sense and is better at RAD than previous VB versions.
My experience is that .Net is like any other tool. Very good for some things and terribly bad for others.
As far as the marketplace for develoment, I recently went through a job search in the Atlanta area and pretty much all of the new stuff I could find going on in the VB world was .Net. Sure there is a lot of legacy VB6 code out there but very little new development seems to be being done in VB6 anymore. .Net is the future of VB whether you like it or not. There does seem to be a leaning toward C# though. I personally prefer VB.NET to C#.NET though it is mostly because I am more used to looking at the syntax and structure of VB than C.
Bad stuff:
1)It is bad for making high speed, compact, small bits of code wether you're accessing it from the web or any other means. It is fast to make these things though and a lot of time building something fast is more important than wether it needs 16000K or 8000K to run. Memory is cheaper than developer time and most apps dont get that high of a utilization rate anyway. The bottleneck is more likely to be network bandwith and database server access time.
2)It has bloat issues.
3)There is a steep learning code if you want to take advantage of its good points.
4)Microsoft World Domination
Good Stuff:
1)Ironically the fact that it is more difficult to appear proficient with .Net that VB6 is really a good thing. The code I have seen developed in .Net is generally much better code than most of the legacy VB6 code I have come across. .Net is trimming out a lot of sub-standard developers who really shouldn't be writing code to begin with.
2)It is excellent for building business applications.
3)It is excellent from an enterprise standpoint. You can build highly scaleable enterprose applications with it a whole lot easier than using C++.
4)A good .Net Developer costs less than a good C++ or Java Developer and they're easier to find.
5)Reasonably descent support for XML
6) Web Forms are not the most effecient but web servers are cheap and easy to setup in a farm. It is fairly easy to add a device specific web interface to a .Net application that is written properly.
7) OOP is possible with .Net.. not so much with VB6. You can argue for or against OOP but in the long run, when it comes to complex, maintainable systems it is the only way to go. You just can't manage a complex system without using at least some concepts of OOP.
8) You can always write C++ components and call them if you really have the need for that kind of effeciency in some calculations etc.
9) MOST OF ALL: Once you go .Net and have to go back to VB6 you will realize just how much better .Net really is. It really just makes business sense and is better at RAD than previous VB versions.
dilettante
MIS
I wish I was seeing this. My experience is the opposite. It seems that over 99% of the ".Net" I see being done is ASP.Net, and that pretty poorly - mostly written by former Classic ASP hacks.
I suspect that in many cases the .Net banner has been picked up by people who are just poor programmers trying to impress somebody with their adoption of "the flavor of the month." When projects fail or overrun their estimates I hear lame excuses about how .Net isn't mature yet (hardly) and that it is all new to programmers (hardly) and will take time before they develop their skills (maybe never happen).
I haven't adopted .Net yet because I haven't had to. The only things I really see "wrong" with it include:
[ul][li]Huge "runtime" with assosciated deployment issues, a hoary chestnut at this point yet still true nonetheless.[/li]
[li]Undue influence from the Java/C++ crowd (VB.Net is an abortion and the delegate/event model in .Net sucks bigtime).[/li]
[li]Additional investment needs to be made in learning the new clothes that old stuff is wrapped in (.Net class libraries).[/li][/ul]
But I do think it is inevitable.
dilettante
MIS
The only issue with the runtime is that it is so large. The 2.0 beta 1 redist package was almost 25 MB (and growing). The VB6 runtime redist package was 1 MB! That's well over an order of magnitude of growth of the problem.
Due to slow OS turnover it isn't deployed on many desktops through distribution during OS installation. With Win2K going "off support" this summer a higher adoption rate of WinXP may end up making the runtime more common as part of the "default" corporate environment.
Then of course the question will be "Which runtime?" since there is one commonly deployed version, an older one, and a new one about to hatch. Still, this should be no big deal - except for the size once again. Maybe newer setup CDs for XP SP2 will come out with all 3 ".Nets" as part of the default install package?
BTW you need to remember that the VB runtime and the JVM were both considered obstacles in the past when drives were smaller and download bandwith more scarce, so this isn't anything new. The big change this time is that the runtime is much larger relative to the applications it supports than in those prior cases.
And if it isn't "a big deal" we'd be seeing 3 versions of the framework (lots of beta 2005 being used today) on a larger share of the deployed desktops... and we don't. Most desktops don't have any version installed. That's what has kept .Net a mainly-server technology. The same thing happened with Java.
Compatibility Considerations and Version Changes
Due to slow OS turnover it isn't deployed on many desktops through distribution during OS installation. With Win2K going "off support" this summer a higher adoption rate of WinXP may end up making the runtime more common as part of the "default" corporate environment.
Then of course the question will be "Which runtime?" since there is one commonly deployed version, an older one, and a new one about to hatch. Still, this should be no big deal - except for the size once again. Maybe newer setup CDs for XP SP2 will come out with all 3 ".Nets" as part of the default install package?
BTW you need to remember that the VB runtime and the JVM were both considered obstacles in the past when drives were smaller and download bandwith more scarce, so this isn't anything new. The big change this time is that the runtime is much larger relative to the applications it supports than in those prior cases.
And if it isn't "a big deal" we'd be seeing 3 versions of the framework (lots of beta 2005 being used today) on a larger share of the deployed desktops... and we don't. Most desktops don't have any version installed. That's what has kept .Net a mainly-server technology. The same thing happened with Java.
Compatibility Considerations and Version Changes
25 MB is still pretty small. How many people install games which require over a gigabyte just to install? How many people install business application which require over 100 MB? And once the framework is installed, it doesn't need to be installed again.
When you say most desktops don't have any version installed, what do you mean? Do you mean worldwide PC's, including those old Windows 98 boxes everyone has laying around, or do you mean business workstations? Also, what do you mean by most? Is it 60%, 70, 80, 90%?
When you say most desktops don't have any version installed, what do you mean? Do you mean worldwide PC's, including those old Windows 98 boxes everyone has laying around, or do you mean business workstations? Also, what do you mean by most? Is it 60%, 70, 80, 90%?
25 MB is still pretty small. How many people install games which require over a gigabyte just to install? How many people install business application which require over 100 MB? And once the framework is installed, it doesn't need to be installed again.
When you say most desktops don't have any version installed, what do you mean? Do you mean worldwide PC's, including those old Windows 98 boxes everyone has laying around, or do you mean business workstations? Also, what do you mean by most? Is it 60%, 70, 80, 90%?
By the way, I'm not sure we can trust a beta version for final specs or even a projection of what they may be. I also find it odd that there would be a large based of deployed applications based on a beta framework.
When you say most desktops don't have any version installed, what do you mean? Do you mean worldwide PC's, including those old Windows 98 boxes everyone has laying around, or do you mean business workstations? Also, what do you mean by most? Is it 60%, 70, 80, 90%?
By the way, I'm not sure we can trust a beta version for final specs or even a projection of what they may be. I also find it odd that there would be a large based of deployed applications based on a beta framework.
I started grappling with VB.NET last year.
At the time I had read an article that stated the .Net framework would be part of all future Windows operating systems. I guess they meant 'LongHorn' ( I'm already starting to think of it as 'LongWait' ). The article also indicated that the .Net framework would be available to other non-microsoft platforms.
If this is the case and it still happens, the runtime issue I think will become a point that no longer can be argued against using .NET. However....I understand we will have a new version of VB this year ( yes another one ) and it looks like it will be a bit of VB6 and .NET. I'm suprised as I would have expected .NET to remain constant until 'Longwait' arrived. Good old Microsoft ( sobs quietly in the corner ).
Dazed and confused
At the time I had read an article that stated the .Net framework would be part of all future Windows operating systems. I guess they meant 'LongHorn' ( I'm already starting to think of it as 'LongWait' ). The article also indicated that the .Net framework would be available to other non-microsoft platforms.
If this is the case and it still happens, the runtime issue I think will become a point that no longer can be argued against using .NET. However....I understand we will have a new version of VB this year ( yes another one ) and it looks like it will be a bit of VB6 and .NET. I'm suprised as I would have expected .NET to remain constant until 'Longwait' arrived. Good old Microsoft ( sobs quietly in the corner ).
Dazed and confused
dilettante
MIS
I'd hazard a guess that far fewer than 1% of Windows desktops have any version of the .Net framework installed today. While WinXP has made some penetration in the home market, it is a rare company that has had the resources in this economy to replace a sizable fraction of its "fleet" of desktops in the last 6 years, and even less so for the past 3 years. For this reason most are still on Windows 2000, if not 95/98/NT4. Businesses don't typically replace the OS that came with their machines.
If they do start moving away from Windows 2000 to XP (instead of sitting on the fence hoping for Longhorn's release so they can sit on the fence waiting for SP 1), then I think we'll see some version of the .Net Framework more widely deployed.
ASP.Net usage of beta .Net 2.0 is becoming widespread, mostly because of the "long" wait time since 1.1 came out and the need to chase the "newest thing" among the counter-Raymon Chen camp. This doesn't really impact the desktop one way or the other though.
The continuing problem with .Net's lack of desktop deployment has led to a dearth of sigificant desktop .Net code though. This is a vicious circle, because a ton of great applications might drive Framework deployment.
You may think 25 MB is nothing, but clearly somebody does. Why else is(are) the Framework(s) so rare on non-developer desktops?
This is a little old (4 months?) but NET vs Java: The War Moves To The Desktop makes it clear worry over the desktop isn't solely a .Net issue. Also see the year-old babblefest at Could .net fail?
What it comes down to is that there are growing pains, and we don't really know what killer event will have to occur before this sort of speculation is history. I think .Net is inevitable myself, if only through the sheer momentum of Microsoft's .Net push to date.
If they do start moving away from Windows 2000 to XP (instead of sitting on the fence hoping for Longhorn's release so they can sit on the fence waiting for SP 1), then I think we'll see some version of the .Net Framework more widely deployed.
ASP.Net usage of beta .Net 2.0 is becoming widespread, mostly because of the "long" wait time since 1.1 came out and the need to chase the "newest thing" among the counter-Raymon Chen camp. This doesn't really impact the desktop one way or the other though.
The continuing problem with .Net's lack of desktop deployment has led to a dearth of sigificant desktop .Net code though. This is a vicious circle, because a ton of great applications might drive Framework deployment.
You may think 25 MB is nothing, but clearly somebody does. Why else is(are) the Framework(s) so rare on non-developer desktops?
This is a little old (4 months?) but NET vs Java: The War Moves To The Desktop makes it clear worry over the desktop isn't solely a .Net issue. Also see the year-old babblefest at Could .net fail?
What it comes down to is that there are growing pains, and we don't really know what killer event will have to occur before this sort of speculation is history. I think .Net is inevitable myself, if only through the sheer momentum of Microsoft's .Net push to date.
- Status
Similar threads
