In a nutshull:

Quote:

No matter how consistent Microsoft is in their marketing message ("just use .NET—trust us!"), most of their customers are still using C, C++, Visual Basic 6.0, and classic ASP, not to mention all the other development tools from other companies.

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 think .NET was a logical follow up for MS.  They felt it necessary to do something to counter the rapid advances Java was making.

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.

I still sneer quite heavily at ASP.Net, but the restis kinda fun :)

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
http://www.insyncva.com

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
www.chelseatech.co.nz/pubs.htm

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

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

I learned the nuts and bolts of VB6 and then moved straight to learning VB.Net.  I have to say I prefer VB.Net.  It's tougth to learn but easier to use and deploy once you have figured it out.

Dazed and confused

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!

My office camps on the fence, developing both web applications and MS VB .Net applications.

The VB is legacy stuff.

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.

Quote:

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.

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:

• Huge "runtime" with assosciated deployment issues, a hoary chestnut at this point yet still true nonetheless.
• Undue influence from the Java/C++ crowd (VB.Net is an abortion and the delegate/event model in .Net sucks bigtime).
• Additional investment needs to be made in learning the new clothes that old stuff is wrapped in (.Net class libraries).

But I do think it is inevitable.

I still don't see what the issue about the runtime is for .Net.  You've got a runtime for Java, a runtime for VB 6, and .Net is on Windows update and being installed on new computers.

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

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%?  

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.

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

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.

>Businesses don't typically replace the OS that came with their machines

We are seeing (and managing) major upgrades to XP on the desktop at all our clients (financial) here in London this year

Really?

I consider that good news.  We're still laying people off in droves here, and the only XP I see deployed is when a PC dies.  Repair exceeds the cost of replacement for typical business PCs these days, and this gives them a feeling they are gradually phasing out at least the tiredest old machines.

Maybe the financial industry is looking up, but anything manufacturing related is on really hard times over in my corner of the world.  We hit 7.3% unemployed here (Michigan, USA) in December, which doesn't count those who have permanently dropped out of the job pool as unemployment benefits expired for them.

I think one could safely say that more than 1 percent of business PC's have been replaced in the past couple of years for new XP machines, so it would have to be higher than that.

I also think that 99% of .Net coding is not ASP.Net.  One could probably get a good guess on that ratio by the number of posts among the ASP.Net, VB.Net and C# forums on this site.

I'm just not convinced that the disk size of the .Net framework is what is keeping it down (if it is fact, being kept down).  I think there are still a lot of VB6 developers who do not feel the need to transition over to .Net right now, as well as developers in other languages such as Java who are perfectly suited to programming in what they currently use.

It would be good to see some large-scale statistics.  I only know what I see around me.  Here, even though almost 1 in 20 desktops have Windows XP now they are mostly a few years old.  Early distributions of XP did not include any version of the CLR, I think it was added to the CDs somewhere between SP1 and SP2.  Both retail edition copies I have at home have no CLR on the CD, but they were pre-SP1.

The number of .Net Framework desktop installations is surely increasing, but I think it will really be driven by successful applications.  Since .Net is more of an internal development tool (like Java) I think this will take the form of "smart client" applications before shrink-wrapped software.

It is just a matter of time.

I agree that adoption will be driven by applications.  The framework is nothing size-wize.  When the smallest hard drives being produced are 40GB, a 25mb framework is nothing.  

Think of a person with a 3-4 megapixel camera.  A handfull of pictures at full resolution and color depth will eat up 25 MB easily.

When programs start being demonstratable more stable and secure due to the built-in bounds checking, removal of raw pointer access, etc.  more people will jump in.

Remember that .NET 2.0 is also being accompained by stripped down, single language versions of Visual Studio aimed at hobbyists.  To go with this is a hugely extended framework to give them many more "building blocks".  The pre-marketing is claiming that 2.0 apps can be developed with half the custom source code to do the same job.

MS is pushing this out top-down and bottom up.  How it will all come together is anyone's guess.

(The .NET Prerequisites CD that comes with MSDN has a volume label of "Office11"....Can anyone say "convergence"?)

Jeff
It's never too early to begin preparing for International Talk Like a Pirate Day

Quote:

a 25mb framework is nothing

I don't look at it so much as a size issue.  I don't care if it's 25K, 25 Meg or 25 Gig--it's another point of failure, another complicated diagnostic mess of version confusion to sort through when things go wrong.   If you write a program under the 1.1 framework and it works differently on newer runtimes, or more likely--write one under a newer framework that doesn't run on the older one, how is that different from dll hell?
--J

>If you write a program under the 1.1 framework and it works differently on newer runtimes, or more likely--write one under a newer framework that doesn't run on the older one, how is that different from dll hell?

Isn't all this conjecture at this point?  
What is the reality?

__________________________________________
Try Forum1391 for lively discussions

I'm going by track record...

Well, there are articles like Compatibility Considerations and Version Changes, though they barely discuss 1.0 because of its low adoption rate.  Framework 1.1 saw much more significant use.

Wow, I refreshed the page and now there's a lot more on 1.0!  Must be something about to happen?

Hmm, maybe x64 adoption will end up being the real driver toward .Net if few other 64-bit Windows developer tools become widely available.

x86 and ia64 and x64, oh my!

I have never shown an interest in VB (or deriratives), and Microsoft's endless use of it in ASP documentation really put me off using their platform.

Old ASP did support other languages but there was sparse documentation, presumably to prevent VB-developers from migrating to alternative languages.

.NET is more inviting because it's documentation is catering for a wider variety of languages: languages which are known outside the MS-camp. This is not a sign of benevolence: it is, ultimately, another Microsoft trap/lock-in!

Once the developers who are familiar/loyal to non-MS languages have migrated to .NET, Microsoft will revert to pushing only a language it dominates (perhaps VB-related) and convert more developers into permanent MS-drones :(

----------
Memoria mihi benigna erit qui eam perscribam