|
|
User Controls
|
New User
|
Login
|
Edit/View My Profile
|
|
|
|
ActiveMac
|
Articles
|
Forums
|
Links
|
News
|
News Search
|
Reviews
|
|
|
|
News Centers
|
Windows/Microsoft
|
DVD
|
ActiveHardware
|
Xbox
|
MaINTosh
|
News Search
|
|
|
|
ANet Chats
|
The Lobby
|
Special Events Room
|
Developer's Lounge
|
XBox Chat
|
|
|
|
FAQ's
|
Windows 98/98 SE
|
Windows 2000
|
Windows Me
|
Windows "Whistler" XP
|
Windows CE
|
Internet Explorer 6
|
Internet Explorer 5
|
Xbox
|
DirectX
|
DVD's
|
|
|
|
TopTechTips
|
Registry Tips
|
Windows 95/98
|
Windows 2000
|
Internet Explorer 4
|
Internet Explorer 5
|
Windows NT Tips
|
Program Tips
|
Easter Eggs
|
Hardware
|
DVD
|
|
|
|
Latest Reviews
|
Applications
|
Microsoft Windows XP Professional
|
Norton SystemWorks 2002
|
|
Hardware
|
Intel Personal Audio Player
3000
|
Microsoft Wireless IntelliMouse
Explorer
|
|
|
|
Site News/Info
|
About This Site
|
Affiliates
|
ANet Forums
|
Contact Us
|
Default Home Page
|
Link To Us
|
Links
|
Member Pages
|
Site Search
|
Awards
|
|
|
|
Credits
©1997/2004, Active Network. All
Rights Reserved.
Layout & Design by
Designer Dream. Content
written by the Active Network team. Please click
here for full terms of
use and restrictions or read our
Privacy Statement.
|
|
|
|
|
|
|
|
Time:
10:23 EST/15:23 GMT | News Source:
ActiveWin.com |
Posted By: Robert Stein |
Welcome to VBTV—the ground-breaking, no holds barred Webcast built for Visual Basic developers by Visual Basic developers! VBTV is a new breed of Web-based seminar—part technical Webcast, part talk show, all Visual Basic .NET. In Episode 3, Chris and Ari come to the realization that they're clueless about Web application development and call in the pros for some much-needed help. Susan Chory and Andres Sanabria, Microsoft's ASP.NET wizards, usher in some yuletide joy and show how nothing tops off the holidays like building Web applications with Visual Basic .NET. So snuggle up next to that PC, crack open the eggnog lattes, and tune in for what promises to be a very, very special episode of VBTV.
|
|
#1 By
20 (24.243.41.64)
at
12/19/2002 11:46:14 AM
|
NO!!!
Do yourselves all a favor, use C#!
|
#2 By
20 (24.243.41.64)
at
12/19/2002 12:13:25 PM
|
Because you're doing a disservice to yourself and the community by using a language that was developed for the sole purpose of hand-holding old VB6 users.
VB.NET has lots of legacy hacks in it that lull developers into doing things the old, procedural way.
Not to mention that VB*.* code is generally less maintainable because it's so ugly.
This post was edited by daz on Thursday, December 19, 2002 at 14:56.
|
#3 By
7390 (198.246.16.251)
at
12/19/2002 2:00:11 PM
|
#6 Kevinu, you are missing something!
http://www.gotdotnet.com/team/csharp/learn/Future/faq.aspx
"Visual Basic, Visual J#, and Visual C++ will indeed support generics at some future date. While this may or may not be in the next major release of Microsoft .NET and Visual Studio .NET, Microsoft will absolutely support the addition of features for consuming and declaring generic types in these three languages within the next two major releases. Moreover, Microsoft will work actively to encourage the adoption of generics in the third party compiler community and will, in the future, include generics as part of the CLS."
in C# and won't be avialable immediately in VB.net
Generics, a form of C++ templates that makes reusing code easier
Iterators, a construct that makes it easier for collections to define the means with which they are traverses using the foreach statement
Anonymous methods, an easier way to perform tasks using delegates
Partial types, a means for programmers to split code across multiple files
|
#4 By
20 (24.243.41.64)
at
12/19/2002 3:01:50 PM
|
Currently, you can do pretty much the same things in VB.NET and C#. There are a few differences, for example, you cannot use unsafe code in VB.NET, nor can you use unsigned types.
C#, OTOH, doesn't have late binding like VB.NET (and for good reason, I might add, but sometimes when you DO need late binding, like for COM, it helps).
The problem with VB.NET is that it includes some runtime libraries that contain old VB6 functions like CInt() and MsgBox() and DoEvents() which shouldn't be used in .NET proper.
However, many VB.NET developers will use these because that's what they're used to. To me, that's not a valid argument for using a language.
Not to mention that VB*.* has horrible maintainability. Trust me, I just spent the last couple months cleaning up after reams and reams of poorly and well written VB code. Even well written VB code is hard to maintain.
In VB *.*, there are more keywords than logic. It's harder to look at the screen and quickly discern what's going on. The keywords blend in with the code and it requires much more concentration to figure out. With C#, the language itself does not get in your way. You can quickly discern what the actual logic is and move on with your code review.
VB.NET was intended for the sole purpose of giving VB6 developers warm fuzzies. For that, it's great. But for serious .NET development, serious object oriented enterprise development, only C# (and maybe J#) should be used.
|
#5 By
1124 (165.170.128.68)
at
12/19/2002 3:22:02 PM
|
MessageBox.Show ()
|
#6 By
20 (24.243.41.64)
at
12/19/2002 4:22:31 PM
|
CInt(): Convert.ToIn32() or cast to (int) depending on the situation
MsgBox(): MessageBox.Show()
DoEvents(): Don't use. Use threads. DoEvents was a hack because VB6 can't do multithreading.
-c
|
#7 By
135 (209.180.28.6)
at
12/19/2002 5:59:04 PM
|
Essentially the main reason why VB6 was popular over C++ is basically eliminated with C#.
C# is a nice language... I don't particularly see it as being grossly better than VB, but I do see a tendency to focus on C# in the industry, and that syntax would be more appropriate to be familiar with.
The one thing people wish VS.NET did that VS6 did was modify code on the fly while in debug mode. You have to keep stopping, recompile, go back in... kind of slow and painful. Maybe they'll add this in the next version, as it would need a JIT compiler or interpreter mode or something in the CLR.
|
#8 By
20 (24.243.41.64)
at
12/19/2002 8:37:58 PM
|
#13: That will only convert a string to an Int32. Convert.ToInt32() converts any type.
#14: You don't see C# being grossly better than VB 6 or VB.NET?
You're right that there's not that much of a difference between VB.NET and C# since most of what .NET is is the framework class libraries (FCL).
But having maintained VB code for several years, I find that VB.NET syntax has changed very little since VB6, I find it offensive that this monstrosity of a language still exists today. It is probably one of the least maintainable languages.
I was also shocked and appalled to find that VB.NET still has On Error GoTo which has to be about the worst error handling construct ever written.
That is, next to On Error Resume Next.
Truth be told, if you want your application to last for awhile and have multiple people maintain it in the future, don't use VB.NET. That is, unless you hate other programmers and wish to inflict great personal harm upon them.
|
#9 By
2332 (65.221.182.3)
at
12/19/2002 9:20:09 PM
|
#15 - I like C# better than VB.NET too, but...
"It is probably one of the least maintainable languages"
Why? I find it no easier or harder to maintain legacy VB than I do VB.NET or C#.
"I was also shocked and appalled to find that VB.NET still has On Error GoTo which has to be about the worst error handling construct ever written."
This is primarily because they didn't want to break every single solitary function ever written in VB while converting to VB.NET. :-) VB.NET also supports try/catch.
"Truth be told, if you want your application to last for awhile and have multiple people maintain it in the future, don't use VB.NET."
Well, I think it depends on what it is, and who will maintain it. If they are libraries only to be accessed via their interfaces, who cares? If the team that maintains them are VB guys, who cares?
Again, I recommend anybody moving to .NET use C#, but if you don't have the time to learn a new language, and you already know VB... VB.NET works fine, and actually does a few things better than C#. Event handling is easier in VB.NET, and so is using reflection to imitate VB6/VBScript/JScript style late binding.
In fact, I wrote some libraries that duplicate VB.NET's ability to simply supply the name (as a string) of the assembly/class, and call a method, arguments and all... in 2 lines of code. That's the way it should be, imho.
This post was edited by RMD on Thursday, December 19, 2002 at 21:21.
|
#10 By
135 (209.180.28.6)
at
12/19/2002 9:44:15 PM
|
The main issues I had with VB6 were all fixed in VB.NET. Those being mainly consistency, lack of good OOP principles, easy access to Windows APIs and so forth.
As far as the language, I actually find it easier to read than C#. But it does require more typing, so it's sort of like COBOL in that regard. :)
|
#11 By
2332 (65.221.182.3)
at
12/20/2002 9:15:42 AM
|
The only problems I've ever had with VB are:
1.) Your stuck with STA... no multithreading.
2.) You can't created poolable objects. (Related to #1).
3.) No bit shifting. (Ever try to parse a DNS packet it VB? You'll see why this one is bad.)
4.) Lack of OO. (Sorry, there is a lot more to OO than interfaces.)
VB.NET fixes all of the above... but I still prefer C# because I find the syntax much more pleasing, and there are a few things that C# can do that VB.NET can't. A big one is creating efficent events.
In VB.NET, you're stuck with "WithEvents"... and if your class publishes many events, things quicky get out of hand... not matter if people are using your events or not.
In C#, you can do it VB-style... or you can conditionally instantiate events on first use. This means they only exist in memory if they are actually being used.
This post was edited by RMD on Friday, December 20, 2002 at 09:16.
|
#12 By
135 (209.180.28.6)
at
12/20/2002 10:53:49 AM
|
JaggedFlame - Good point. VS.NET has intelliwhatever for VB where it doesn't for C#. I don't understand that.
Also VB is not case sensitive, which I honestly still find annoying in C# even though I spent years with C. There is no reason why 'If' shouldn't be the same as 'if'.
|
#13 By
20 (24.243.41.64)
at
12/20/2002 12:12:20 PM
|
#22: The only reason VB needs that is because it's so verbose. C# doesn't need it because filling in blocks like that would be of little use.
As far as case sensitivity, that's one of the main reasons against using VB. It's not about 'if', it's about having identifiers with various different casing throwing off would-be maintenance programmers.
Please see How To Write Unmaintainable Code:
http://www.mindprod.com/unmain.html
This talks about a lot of the stuff I've mentioned including creative mis-casings, abusing VB's horrible error handling, etc.
The problem with VB.NET is that is has far too much VB6 crap in it that should've been ditched, like the On Error GoTo. Yes, I know VB.NET supports try/catch, but the simple fact that On Error GoTo exists is cause enough to question the validity of the language.
Far too often, people underestimate the cost of maintaining code. The cost of software is about 10% development and 90% maintenance. Using a language like VB automatically increases your maintenance costs just because it's harder to maintain than other languages.
Add to this that the average experience of VB users is lower, so the code is generally of less quality which makes it a nightmare.
I could fill pages of some of the stupid hacks and tricks I've seen during years of maintaining VB code. It's not to say someone couldn't do tricks in other languages, the main point is:
VB allows poor programmers to program poorly.
It keeps them in this little bubble that allows them to keep on doing things wrong and poorly.
Learning C# allows them to open their eyes a little and see what's really going on and why many things about VB and VB.NET are really WRONG and shouldn't be there in the first place.
There was strong debate in MS about whether to develop VB.NET, but in the end, it was mainly a marketing decision because there were so many VB developers who would refuse to learn something new. It's unfortunate that MS had to cater to them rather than force them to learn proper ways of doing things.
I shutter at the thought of the millions of lines of code being written out there using CInt(), abusing late binding, using On Error GoTo, etc.
|
#14 By
20 (24.243.41.64)
at
12/20/2002 1:12:05 PM
|
if you're using Visual Studio, case sensitivity isn't really an issue, either, because it's automatically corrected for you.
So go ahead and keep writing crappy code and hope that every instance is caught for you. Good plan! Encourage sloppy programmers to keep programming sloppily.
I still can't find a good reason to use VB.NET. If you're coming from VB, there's a host of new things you must learn anyhow, so why not go to C# and do them right rather than work with the hacks in VB.NET?
This opinion is probably bound to change if I ever start working at a corporation
Oh man... let me tell you. Spend 6 months maintaining VB code, ANY VB code and you will grow to loathe it as have I.
|
#15 By
20 (24.243.41.64)
at
12/20/2002 5:59:27 PM
|
Right, feeding the addict. And VB.NET is ok for that, I guess. But that doesn't change my argument that you should be using C# :)
If you don't want learn something new, then use VB.NET
|
#16 By
1845 (12.209.152.69)
at
12/20/2002 11:58:21 PM
|
daz, I hate vb as much as the next man, but I've got to say your rantings make you sound rather foolish. A poor programmer can write bad C#. A good programmer can write good VB or VB.Net. I've written thousands of lines of VB6 that are quite maintainable because the apps were well designed, documented, and used standard and consistant code styles. My C# is just as maintainable for the exact same reasons.
|
|
|
|
|