The Slow Brain Death of VB.NET

ICR -

  • Thanks for your point of view! I appreciate the fact that you and I have a fundamental difference of opinion, which might(?) best be summarized as that you are looking to the future of .NET as being positive, where I am looking at what it is right now and feeling very disappointed.

  • No offense intended, since you were respectful of my point of view, but I can remember when C++ was the new and up-and-coming thing. Microsoft could point directly at Word and Excel to show you just where, exactly, you could get to using the product.

  • My point is that there are amazingly few apps, and none of the complexity and usefulness of any of the Office components, that can be used to promote the underlying strengths of .NET at this point - not even apps provided by its authors.

  • In future, hopefully, .NET will, as you state, provide a lot more than non-.NET. Until you get to that point, you cannot make the case that users need to upgrade (pay more $$$) to get the newer version of your software after they pay for the new Vista software and the new hardware they need to run it, etcā€¦

  • IMHO, it will be quite a while for the user community to be at the place where deploying a new app in .NET will be cost-efficient for the author (me).

  • Not to belabor Clayton, but people moved on from DOS to Windows 3 because it provided clear and immediate benefits. Ditto for Windows 95 over both DOS and Windows 3. Having reviewed the beta for VISTA, it simply does not provide anywhere near as compelling a reason to upgrade. Looks nicer, but there are several areas of cost to address - and WinXP works just fine, thanks!

  • And similarly (though for different reasons) .NET does not provide a truly compelling reason to adopt it (YET).

ā€œI can remember when C++ was the new and up-and-coming thing. Microsoft could point directly at Word and Excel to show you just where, exactly, you could get to using the product.ā€

Office was, and still is, built upon a huge legacy code of pure C, even Office12. So I donā€™t know how they were showcasing it. But your point remains valid

And yes, it does come down to two differing views. I suppose because I am not a developer by profession I am not so conserned about the here and now and can afford to look to the future.

SiGiD
Unstable? Youā€™re kidding right? I have many, many applications that are used every day that are written in C#. Not a peep from my end users. Of course they are all running on Win2K pro or higher. A Dell desktop only cost 400.00 each if you buy in bulk. If your clients canā€™t scratch that much out of a budget then custom apps are the least of their problems.
No, I donā€™t think that you or anyone that shares your opinion is stupid. My opinion is worth no more or no less than yours. Itā€™s just an opinion and just because we disagree does not mean that either of us is inferior.
I just become irritated because every time something new comes out thereā€™s this huge backlash of concern over its stability or its cost effectiveness. Example: People went berserk when Windows 2000 came out. Its no better than NT, Bloated Code, unstable and so on and so forth. After all the complaining and screaming that the sky was falling was over, Windows 2000 WAS better than Windows NT just as Windows XP IS better than Windows 2000. Itā€™s evolution, the crap that was broken or clunky in the previous version is ultimately corrected in subsequent releases. Like it or not Windows XP was derived from Windows NT. VB.NET is ultimately derived from Visual Basic 6.0 even if it is radically different.
I research every aspect before making a decision. Thatā€™s what I do. My decision to expend time and money to learn C# was not made because of a shinny box. I read the hype, then I did my homework and .NET has (in my opinion) some really fresh and innovative concepts at its core.
Another positive aspect is that it will trim down the wannabes that currently comprise about 2 of the 6 million purported VB programmers. If youā€™ve debugged some of the code out there that passes for legitimate you know what Iā€™m talking about. VB 6.0 is too easy to fakeā€¦ It takes more than copying and pasting MSDN samples to write stable code.

Clayton:

  • Is your assumption is that anyone not wholly embracing .NET (which is totally new, unproven, unstable, and a truly horrific example of code bloat) is either too stupid to learn it or is simply afraid of anything new?
  • How about a third option? That .NET really does not provide any capability that Win32API programming does not already provide, so why bother with it just so as to keep money flowing back to MS? I have, like you, already learned .NET - but I have been forced to conclude that it is not worth using since it does not allow me to provide stable software to my customers. Maybe in the future end users will upgrade their hardware so as to be able to run .NET, but making a cost benefit case for doing it today (or in the near future) simply does not work. Yet. And maybe never.
  • Question: If .NET is REALLY so wonderful, why does Microsoft not produce anything that uses it? Note that Visual Studio is written against COM, and the new Defender/OneCare product is a big ditto. How come its supposed to be good enough for you or me or anyone else when even its authors have no practical use for it?
  • Question: If .NET is REALLY so wonderful, why does Microsoft not produce anything that uses it? Note that Visual Studio is written against COM, and the new Defender/OneCare product is a big ditto. How come its supposed to be good enough for you or me or anyone else when even its authors have no practical use for it?

They are producing plenty. Microsoft Expression Interactive Designer (Sparkle) is all managed code. Alot of Vista is managed code (The first componant that comes to mind, the volume control Iā€™m pretty sure is. There is ALOT more though). Alot of the new software is being written in managed code (these are two of a few examples that I know of, I just canā€™t remember what the others are off the top of my head, and canā€™t research it now). Visual Studio has a large amount of legacy code. You really expect them to re-write the entire thing in managed code? That is just unreasonable.

  • How about a third option? That .NET really does not provide any capability that Win32API programming does not already provide, so why bother with it just so as to keep money flowing back to MS?

Currently, no, it doesnā€™t provide a whole lot else, but it does make it alot easier. But in the future, it will provide alto more.

"significantly different from (and incompatible with) previous versions."
I havenā€™t looked exaustivly at the changes between versions, but all the changes I have come across either:
a) Keep the old commands (at least for the next version) and issue a compiler warning saying they are redundant. Most of the cases are just changing a function name, or only a small restructuring of code.
b) They provide a more efficient, better way. But the old way still works.
So I see no huge breaking changes that force you to completely rework your code if you upgrade between versions. There not completely stupid.

And actualy, MSBuild is written in managed code, so a large part of visual studio is managed:
"MSBuild is a departure from building in previous versions of Visual Studio as it is written in managed code, with high performance and extensibility as goals."
a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/VS05feat.asp"http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/VS05feat.asp/a

  • I must say that I am impressed by the civility of the contributors to this post! Most refreshing that ad hominem attacks are not the order of the dayā€¦

  • Clayton, I agree with you that we simply disagree on the ultimate value of the .NET direction. And yeah, it probably does look like the usual ā€œI donā€™t want anything newā€ syndrome that always accompanies new technologies.

  • To my mind, any new programming tool that offers no new capabilities but still costs - both dollars for the new tools as well as programmer time to climb the learning curve - as though it does is simply a poor investment of my (admittedly limited) time and resources.

  • And it is focussed upon a hardware/software platform that, as I said already, requires significant new investment on the part of the end user community to adopt. True, a Dell can cost only $400 or so, and Vista may be approx another $400 (this is a guess) on top, you are still talking only about $800 - except that when your end user community is a corporation with multi-hundred end users to upgrade and retrain and have IT offer support to, the true cost goes up exponentially. The battle is for perceived cost benefit, and businesses face this every day. When the total cost starts to exceed $100,000, you have to make a very good case to convince the multiple layers of management that must sign off on this captial budget line item that they will re-coup their costs over a defined period of time, or you get a great big ā€œNo, thanks!ā€

  • And, sorry to say, my comment about ā€œunstableā€ refers not only to the incredibly buggy VS2005 IDE but also to apps written with it - especially those using ADO.NET (which makes the old versions of ADO look positively excellent by comparison).

  • I suppose that time alone will settle this debate. Maybe we can agree to rejoin this discussion at some future point to see where the market is going / has gone to see whether I am too pessimistic or you are too optimistic :wink:

SIGID,
Hey this is scaryā€¦ All my apps are written using ADO.Netā€¦ still not a peep from my people. I just had approval for $120K capital project with a subsidiary of HSBCā€¦ This does not include any workstations (only software and one server). Any business operating on a national or international scale relies on computer software and hardware to function. Itā€™s a necessary business tool to operate not a perk that someoneā€™s kid is getting. If a company of hundreds of users canā€™t produce $100K for operations they have serious cash flow issues. Example: In 1998, I used to install and configure turn key accounting systems (Windows NT 4.0) complete with Exchange Server 5.5 (Exchange 5.5 is perfect example of instability but thatā€™s another story). During a follow up visit, I would often discover that Exchange had blue screened about a week after it was installed and had been down for at least a month. Most clients didnā€™t even notice it had been down. Let Exchange fail today and the company literally ceases to function. When the accounting system goes down there are no ā€œbooksā€ to fall back on. Business operations simply stop. When the distribution or supply side of your infrastructure fails the lost revenue can easily exceed $200K in a 100+ user facility.
I use Visual Studio 2003 Enterprise Edition with the 1.14 framework. I did take a quick glance at VS2005 Beta 2 with the 2.0 framework but experienced a few glitches myself and decided to stay put for awhile. I did notice that the DB Connection and Data Adapter objects were different compared to VS 2003.
As for our difference of opinion, diveresity is a human phenonoem. If human nature was to agree on all matters we would still be living in caves.
I had this same discussion with a soon to be EX software vendor about two months ago. I merely asked him why he had not migrated his application to .NET or some more modern language than VB 6.0. He replied ā€œ.NET, that stuff is buggyā€. So I asked him to elaborate with some examples. He could not. I then asked him to give one example. He could not and immediatley became defensive. If I make a statement like that, I can always back it up. So, I guess you know whatā€™s coming next right? Would you please give me a few examples of ADO.NET instability? If not a few then one example will suffice.

I prefer VB.net over c# because I hate the {} hell that you have to type. VB.NET uses white space (i.e. the return key which is natural)and addes the end function/sub/class statements. VB.NET also has better intellisense. The VS2005 code snipplets and My class also makes coding a lot faster.

The only problem with {} that I hate is the fact that there a shifted character - wth? But Iā€™m so automated to shifting for it that Iā€™m scared to remap it.
I suppose the only real reason why I prefer C# over VB is not any objective ā€œit has thisā€, but because Iā€™m just more used to, and more at home with the C syntax. Iā€™ve been using it for many a year now. And anything close to the VB syntax I have used (VB and Delphi) have been in old IDEā€™s that make working with the verboseness alot harder and an uphill struggle.
I have been working with VB recently (converting some of Jeffs projects no less) and I still donā€™t really prefer it from a readability standpoint. Maybe I will have to start writing in it someday.

SiGiD,
What flavor database are you querying and how are you establishing a connection to it? I assume that youā€™re using the server explorer in the IDE?
Some of the older database platforms act strangely with the '03 IDE (the older flat file stuff in particular). However this can usually be traced back to some third party ODBC emulator. But you can work around this by tweaking the connection string in some cases. A flakey network connection will also wreak havoc on the IDE too. Yes she will drop like a stone! Pull a ā€œSelect Allā€ and then disable the network connection with it in the active window if you donā€™t believe me.
I agee that a big freeze or inconsistent query results are a cause for serious concern. How does the IDE respond on simple single table querys (no joins)? If itā€™s freezing on those you may have some issue with an ODBC driver or connect string.

Clayton -

  • Hello again!

  • I agree that companies should regard hardware/software as a ā€œcost of doing businessā€. However, consider that the upgrade to Vista / .NET would occur MUCH faster and more easily if there were a ā€œcannot-live-withoutā€ type feature to drive the expenditure. Otherwise, most business folks just take the approach ā€œif it ainā€™t brokeā€¦ā€.

  • This is why I feel the .NET apps are further in the future in terms of becoming widespread (the idea behind ā€œhow long can you go without a paycheckā€) - but it depends on who your end user market really is, I suppose. My experience has been in the finance industry, and these people know the value of a dollar and are shall we say reluctant to part with any unless absolutely necessaryā€¦:wink:

  • And for customers who do not choose to be on the cutting edge, VB6-type people will continue to be gainfully employed for some time to come, and since the entrenched programmer always knows the business better, (s)he will remain employed helping move that cruddy old legacy code up to .NETā€¦:wink:

  • Iā€™m afraid the code Iā€™m working on is proprietary so I am not free to provide actual non-working code samples (and the data is, too, of course!), but I can describe the issue in general as a continuing problem with what should be simple SQL statements either returning differing result sets or simply failing to return at all - not even an error message, nor a blue screen, just a ā€œbig freezeā€. This all occurs within the IDE, if that explains anything.

  • I compare this result to the exact same code being run under old VB6 against the same back end database, and find that we do not get any unexpected results - i.e., it runs fine. Do you have, maybe, any insight into what might cause this sort of issue (Iā€™d REALLY appreciate a fix for this!!)? You certainly seem to be having better luck with it than we haveā€¦when we see this result occur within the IDE, we certainly have NO interest in sending out any apps to any of our customers!

Clayton -

  • Your thinking on this matches what we have so far come to regard as being correct. The third-party DB is fairly old and the ODBC is provided directly by the publisher; we are not real sure how to tell if the issue definitely lies wholly within the ODBC driver or with some quirky ADO interaction with it. So far, all we know for sure is that the DB publisher certifies that their stuff plays well with ADO and MS feels that ADO could not be causing this bug (does this sound at all familiar??)
  • The network connections are fine (no evidence of any problem).
  • The SQL queries are pretty vanilla; no JOINS of any type. Mostly straight SELECTā€¦WHERE statements, with a few calcs thrown in as needed. We tried re-creating the table indices, and even rebuilding the table structures, but found no issue there. If only we could get an error return of some sortā€¦(never thought Iā€™d be hoping to see an error return, but at least it would be a place to start!).
  • What DB do you use, if you are free to say? Is it a Microsoft product or some other?
  • And thanks again for all your time and trouble; I appreciate the fact that, without having more detail than I can give you that your ability to provide insight is limitedā€¦

Jeff -

How about updating your position on this post. Still feel the same way now that YOUā€™ve switched to C#? Do you feel your assessment of VB is coming to pass?

Would love to know your [updated] thoughts on this postā€¦

SiGiD,
OKā€¦ Sounds like you have the classic finger pointing session.
Simple queries arenā€™t working.
The network is good.
I had a similar experience happen a few years ago. We were writing an application that provided custom financial reporting (simple right?) The database was an older Betrieve type that had ODBC connectivity furnished by the provider. We duplicated several tables using MSSQL 2000 and our problems vanished immediately. We then started investigating the ADO.Net interaction with the ODBC and learned that the Odbc.OdbcDataAdapter.Fill, Update commands were not compatible. We worked around it by using the Odbc.OdbcDataReader! We used the Odbc.OdbcDataReader and Odbc.OdbcCommand objects without any further issues. So my advice is that if you are bound to an older non-relational database, you may want to avoid using the OdbcDataAdapter.
Once we stopped using the OdbcDataAdapter we could read and write using the DB Provider ODBC without any errors.

Chill out dudes - This discussion is all for not. In a short few years you will be able to program in the language of your choice and not be persecuted, courtesy of .net and the evil doorers at Microsoft. There wonā€™t be such a thing as a c# or VB shop. Language converters will mitigate this minor detail. So relax.

Oh and by way, VB is the best language on the planet. -Shake yoh booty.

I once said on my site that I wouldnā€™t sell out and convert to VB.NET - my argument was that VB6 was still alive and there was no need to jump on the bandwagon. Having started to use the VB.NET Express IDE (which is incredibly slow and counterproductive, despite the vast array of controls), I think Iā€™m going to stick with VB6 until it folds, and then Iā€™m moving to Java or even C#.

The move to .NET or J2EE and which language to use is dependent on management being enticed by either camp but mostly what camp they already are in. The move towards .NET is growing and J2EE is waning. Do J2EE jobs outweigh MS as a whole. MOst likely but that trend is decreasing.

.NET is gaining ground. There are two related reasons why. If a Microsoft team feels the need to upgrade, they will do it in accordance to what they are currently working with. The cost of moving from a COM platform to J2EE is far greater than to .NET. Granted there is no straight line in converting.

.NET also gives the ability to develop with the VB, C#, C++ and other CLR compliant languages along the same projects. Therefore retraining in ā€œforiegnā€ languages is lessened. With a vast number of VB programmers out there, making the switch to C# will be easier if a VB 6 developer moves first to VB.NET. Theres is that comfort in the womb factor.

With that said, VB developers can make a fair transition to VB.NET, especially those that are strong, professional software engineers. Hacks will definitely have more difficulty making the transition. Therefore, .NET will help separate the wheat from the chaff.

I believe, like myself, VB programmers WILL make the transition to C# as the common language for developers, which will also include Java programmers seeing the light down that tunnel called the future. .NET offers a flexibility that J2EE doesnā€™t offer (well more than oneā€¦) Movement from one language to another while remaining in the same framework. This with the familiarity of one vendor though not ā€œstuckā€ with one vendor, as a viable reason for management to move towards migrating towards .NET which is NEVER a rapid flow as is whipping out a quickie prototype in VB. Only time will tell what happens to VB. COBOL (yuck), RPG and yes my favorite tool VFP are still alive and kicking. So expect VB to not go away, but in the near future, expect C# to become the de facto language of the development world of the serious professional software engineer.

Rick, are you sure your real name is not Micheal Flanakin? Cause you sound exactly like him - and that is NOT a compliment unless you enjoy being a pompous, arrogant buffoon who believes that ā€œtalentā€ can offset crippling personality defectsā€¦

ā€œSeparate the wheat from the chaffā€? Get over yourself and recognize that programming is an art form - and in programming, just as in fine art, ā€œIt isnā€™t the paintbrush, itā€™s the artistā€.

No, bad programmers we shall always have with us - whether .NET or not, and whatever language they choose to (mis)use.