The Wacky World of Visual Basic
-
In VB6, if you want to rename a file, you don't call a function like MoveFile(). That might make sense.
No, they have special syntax for it:
Name oldpathname As newpathname
Just for that one function call, they added a new syntactical construct to the language. Just for fun, it mimics the declarator syntax. Because declaring a variable and renaming a file are such similar operations, I suppose.
Why was there no adult supervision when that language was designed?
-
I just love the way compilers dont warn for imposibilities:
if (1 == 2)
or
while ( 1 != 2)
-
@Edgar Plonk said:
In VB6, if you want to rename a file, you don't call a function like MoveFile(). That might make sense.
No, they have special syntax for it:
Name oldpathname As newpathname
Just for that one function call, they added a new syntactical construct to the language. Just for fun, it mimics the declarator syntax. Because declaring a variable and renaming a file are such similar operations, I suppose.
Why was there no adult supervision when that language was designed?
You've gotten it backwards: the "Declare foo as bar" syntax is what they added.
NAME "x" AS "y" is a holdover from GW-BASIC days. Take a look at KILL, too.
-
And don't forget that variable declaration in VB has it's own WTF:
Dim a, b As Integer
is the same as:
Dim a as Variant
Dim b as Integer
Argh!
I can't see any reason for this at all. All it does is makes you type 10x as much code for variable declaration.
-
@mallard said:
And don't forget that variable declaration in VB has it's own WTF:
Dim a, b As Integer
is the same as:
Dim a as Variant
Dim b as Integer
Argh!
I can't see any reason for this at all. All it does is makes you type 10x as much code for variable declaration.
VB stopped doing that 5 years ago. In VB.Net, you get two Integers.
-
@Hitsuji said:
I just love the way compilers dont warn for imposibilities:
if (1 == 2)
or
while ( 1 != 2)
Use a non-sucky compiler. Even one with trivial dead-code elimination will optimize that away, and most will warn as well.
-
OMG VB sux0rs LOLz!!!!!111won
Hitsuji: What does "if (1 == 2)" have to do with VB's file renaming syntax? You're using C-style code in your example, we're talking about that other language.
mallard: Yeah the Dim thing is annoying because you have to declare the type for every variable. So you have to type "As Integer" twice, or maybe copy/paste. It's been like that for awhile though, this isn't a recent development.
Welcome to the 1990's everyone. Most of us are moving over to .Net because these problems are fixed now. I'd recommend you do the same. Is this really the best side bar WTF you had?
-
@jsmith said:
@mallard said:
And don't forget that variable declaration in VB has it's own WTF:
Dim a, b As Integer
is the same as:
Dim a as Variant
Dim b as Integer
Argh!
I can't see any reason for this at all. All it does is makes you type 10x as much code for variable declaration.
VB stopped doing that 5 years ago. In VB.Net, you get two Integers.
I consider VB.Net to be an entirely new language. So "VB" has not stopped doing that and probably never will, unless MS decide to introduce a new version.
-
@Hitsuji said:
I just love the way compilers dont warn for imposibilities:
if (1 == 2)
or
while ( 1 != 2)
C compilers tend to assume that you said what you meant. And so they should.
-
@Manni said:
Welcome to the 1990's everyone. Most of us are
moving over to .Net because these problems are fixed now. I'd recommend
you do the same. Is this really the best side bar WTF you had?
I'm not a VB user; I'm a programmer. I had to fix a bug in VB6 legacy
code, in which I saw this "Name" gibberish and said to myself, "WTF?!".
If I were required to reimplement the whole mess in VB .NET, or
implement anything at all in any kind of VB, I'd find another job. I
try to go along and get along, but there are limits. Imagine
interviewing for your next job, and having to explain that you spent an
entire project writing VB code. Imagine having VB on your resume; how
would you ever get a real job again?
-
@Hitsuji said:
I just love the way compilers dont warn for imposibilities:
if (1 == 2)
or
while ( 1 != 2)
Reminds me of my favourite interview question I got asked as a junior dev. They asked (for Java) what the difference between these two statements was:
if ( false ) {
System.out.println( "Hello, world!" );
}
while ( false ) {
System.out.println( "Hello, world!" );
}
It's a tough question to answer when you're not next to a compiler. I'd still maintain that someone in an interview who could give me an instant answer to this and the reason behind it, I'd strongly consider giving the job to on the spot.
-
@Edgar Plonk said:
In VB6, if you want to rename a file, you don't call a function like MoveFile(). That might make sense.
No, they have special syntax for it:
Name oldpathname As newpathname
If anyone's interested, I'm pretty sure this is a throwback to much older versions of Microsoft BASIC, including BASICA and GW-BASIC.
If I'm writing VBA or VB6 code now and I need to do file stuff, I usually use the FileSystemObject class and related classes from the Windows Scripting Host library. It makes code more readable.
-
VB6 is sane compared to the version of BASIC that I worked with years ago.
2 points for anyone who can name the version of BASIC where this syntax is legal:
GOSUB LABEL1
PRINT "Returned from GOSUB"
LABEL2:
...
LABEL1:
...
RETURN TO LABEL2
-
@Edgar Plonk said:
@Manni said:
Welcome to the 1990's everyone. Most of us are
moving over to .Net because these problems are fixed now. I'd recommend
you do the same. Is this really the best side bar WTF you had?
I'm not a VB user; I'm a programmer.
sigh I bet you program in binary and eat nails for breakfast too, right? How do you manage such a large e-penis?
@Edgar OMGZORZ VB LOLERHAHA Plonk said:I had to fix a bug in VB6 legacy
code, in which I saw this "Name" gibberish and said to myself, "WTF?!".
If I were required to reimplement the whole mess in VB .NET, or
implement anything at all in any kind of VB, I'd find another job. I
try to go along and get along, but there are limits.
Can you explain to me why that is? Honestly, I don't get it. It's not physically painful to write code using VB syntax, so what the's problem? If you can do what's required of you using VB, then why not? Seriously, I'd love to have this explained to me.
@Edgar I love elitist bullshit Plonk said:Imagine
interviewing for your next job, and having to explain that you spent an
entire project writing VB code. Imagine having VB on your resume; how
would you ever get a real job again?
Edgar's Consturction Company: Hmmm...Mr. Midriff, we see from your resume that you primarily used a screwdriver at your last job. Can you explain why?
Mr. Midriff: Well, my primary duty there was to turn screws. A screwdriver, provided to me by the employer, seemed the best tool for the job.
ECC: But we hate screwdrivers. We use hammers here, only hammers.
M: Oh, I see. Well, as you can see from my resume, I've plenty of experience using hammers as well.
ECC: Smirks Right. But, you used a screwdriver...would you have us believe that any construction worker worth hiring would use a screwdriver?
M: Well...ummm...well yes, if that's what his employers require of him. Plus, the screwdriver really is the tool for the job of turning screws.
ECC: ...
M: ...I mean, sure, you could pound in a screw with a hammer, but I can hardly see why you'd want to do that, especially if, as in my case, your employer provides you with a perfectly capable screwdriver.
ECC: "Perfectly capable screwdriver!" Heh, that's a good one.
M: ...
ECC: ahem Well, Mr. Midriff, we certainly appreciate your time, but we're afraid you're not quite what we're looking for.
M: Oh. Well, I uh...
ECC: We're looking for construction worker of a higher caliber, not one who would use a screwdriver.
M: ...
-
BTW, through VB6 nothing was ever taken out of the language as it evolved. GOSUB, PRINT, INPUT, KILL, NAME, LET, CALL and a slew of other statements that no one should ever use were kept around for backwards compatibility. Is it so horrible that MS decided to allow people to upgrade code without breaking it?
Using those statements is horrible, but it's not Microsoft's fault. I once met someone who told me they were going to stick with VB6 because .Net had done away with GOSUB.
Also, VB.Net is the upgrade to VB6. It was even called VB7 internally for a while. If you choose to believe otherwise then you'll never see an upgrade to VB. I suppose it's fine that some people won't associate the weaknesses of legacy VB with VB.Net. MS is taking their time getting rid of VB6, but eventually they'll come out with VBA.Net and a .Net script host.
As for VB.Net being a bad language, that's rediculous. Functionally equivalent VB.Net and C# compile to exactly the same MSIL. Nearly every feature of C# is accessible in VB.Net. Many sophisticated techniques are easier in VB.Net than C# (think events). At the end of the day it comes down to a few small differences. The C# compiler is more strict, finding some common errors for you (like uninitialized variables and a more obvious pass by reference syntax). The VB.Net development environment is more dynamic and able to syntax check code as you type it instead of waiting for a rebuild. It just comes down to whatever language you can get the job done in. I do both C# and VB.Net every week and neither makes me cringe. JavaScript drives me frickin' nuts.
-
I've been programming for 22 years now. I've no experience with VB.NET but for my current job I need to use VB, and not the .net edition but its older ilk. Now, I know quite a few languages, I know architecture, I know what ir required and desirable from languages, and after having studied up on VB I must confess to go Wft?! on almost every page of the books and sources I studied (at least until I got habituated to being in some dystopically cynical programming kind of Alice's Wonderland). Now I don't go wft anymore, and I accept the existance of the language, but I maintain that it has to be the most inconsistent, worst designed language I've ever seen.
Just as a point in case: what's with the special syntax for particular procedure calls? Since when do you make special compiler exeptions for certain standard procedures?! sigh
-
@Mikademus said:
I've been programming for 22 years now. I've no experience with VB.NET but for my current job I need to use VB, and not the .net edition but its older ilk. Now, I know quite a few languages, I know architecture, I know what ir required and desirable from languages, and after having studied up on VB I must confess to go Wft?! on almost every page of the books and sources I studied (at least until I got habituated to being in some dystopically cynical programming kind of Alice's Wonderland). Now I don't go wft anymore, and I accept the existance of the language, but I maintain that it has to be the most inconsistent, worst designed language I've ever seen.
Just as a point in case: what's with the special syntax for particular procedure calls? Since when do you make special compiler exeptions for certain standard procedures?! *sigh*
Remember the insane level of backward compatibility they were trying to achieve. Bill Gates first real-world job was writing BASIC compilers/interpreters for computers in the 70s. They did one for the Altair that had 256 bytes of RAM. Some of the constructs in BASIC are realllllllllly old. They are preserved for backwards compatibiity only. There are sane alternatives to 90% of them, using the insane syntax is the developers fault. Of course, VB6 did have some WTF level quirks, like the rules on parentheses when calling a function.
-
I don't have a java compiler at hand, but let my try to answer anyway :}
(So the following might be wrong, it's a few months since I had to implement that check in our compiler writer course)if ( false ) {
System.out.println( "Hello, world!" );
}
The code above wil compile fine, but it will not have any effect.while ( false ) {
System.out.println( "Hello, world!" );
}
The code above will cause the compiler to complain about the fact that system.out.println("Hello, World") is unreachable code.
But the real question is: Why this difference :}
The reason is that java have a special rule for handling final boolean in if. (And afair only in if)
final boolean myBool = (true or false);
Because myBool is final, Java is allowed to substitute all tests for myBool with the value of bool when doing if(myBool).
That is: For java the following code is equivalent:
if(false) {
doSomething();
}
---------------
boolean myBool=false;
if(myBool) {
doSomething();
}
So if java did not allow if(false) testing a final boolean in an if, would not be legal.
The reason that the same rule does not apply for the while(false) case is that
writing
final boolean doDebug=false;
// Code ...
if(doDebug) {
printf("Debugging");
}
Is normal but I can't come to any reason while anyone would want a for/while loop
which tests a final boolean.
But sorry, I am not looking for a job right now :}
Martin Tilsted.
-
-
@mallard said:
I consider VB.Net to be an entirely new language. So "VB" has not stopped doing that and probably never will, unless MS decide to introduce a new version.
hmm... interesting. They "fixed" VB by removing all the old syntax, cleaned up the language, and released it as VB.NET. Yet, because of this, you have decided, this is no longer VB and not an upgrade of VB.
Yet, at the same time, you are saying that the "real" VB will never be "fixed" unless they release a new version .... You do realize that in order to "fix" the "real" VB, they will have to break compatability with older versions, right?
think about that a little bit.
-
@Jeff S said:
@mallard said:
I consider VB.Net to be an entirely new language. So "VB" has not stopped doing that and probably never will, unless MS decide to introduce a new version.
hmm... interesting. They "fixed" VB by removing all the old syntax, cleaned up the language, and released it as VB.NET. Yet, because of this, you have decided, this is no longer VB and not an upgrade of VB.
Yet, at the same time, you are saying that the "real" VB will never be "fixed" unless they release a new version .... You do realize that in order to "fix" the "real" VB, they will have to break compatability with older versions, right?
think about that a little bit.
It's not that they broke compatibility, it's that they replaced it with a language that isn't "VB7" no matter what they called it internally. VB6 was a language that could trace it's ancestory all the way back to GWBASIC. It was a quasi-object-oriented language for writing Win32 applications.
If VB.Net was the same language, then porting applications from VB6 to VB.Net would require changes, but not a complete rewrite. For any non-trivial application, porting to VB.Net does require a complete rewrite. Features only fairly recently introduced, such as usercontrols, have been dropped.
VB.Net is an alternative syntax to C# designed (IMHO) to allow programmers to more easily transition from VB6 to C#.
-
@mallard said:
@Jeff S said:
@mallard said:
I consider VB.Net to be an entirely new language. So "VB" has not stopped doing that and probably never will, unless MS decide to introduce a new version.
hmm... interesting. They "fixed" VB by removing all the old syntax, cleaned up the language, and released it as VB.NET. Yet, because of this, you have decided, this is no longer VB and not an upgrade of VB.
Yet, at the same time, you are saying that the "real" VB will never be "fixed" unless they release a new version .... You do realize that in order to "fix" the "real" VB, they will have to break compatability with older versions, right?
think about that a little bit.
It's not that they broke compatibility, it's that they replaced it with a language that isn't "VB7" no matter what they called it internally. VB6 was a language that could trace it's ancestory all the way back to GWBASIC. It was a quasi-object-oriented language for writing Win32 applications.
If VB.Net was the same language, then porting applications from VB6 to VB.Net would require changes, but not a complete rewrite. For any non-trivial application, porting to VB.Net does require a complete rewrite. Features only fairly recently introduced, such as usercontrols, have been dropped.
VB.Net is an alternative syntax to C# designed (IMHO) to allow programmers to more easily transition from VB6 to C#.
So, basically, you reserve the right to always complain about VB -- no matter what Microsoft does.... Since VB.NET is a new language in your mind, it doesn't solve any of VB's problems. So, you ignore VB.NET and all of it's merits when discussing VB. And if they did release a new version of VB that does solve those problems, by definition it will not be backwards compatable since many of those things we complain about (error handling, type checking, quasi-OOP model, weird syntax of old BASIC commands, hard-coded "commands" in the language instead of class libraries, the old "ruby" form model, etc) will be removed, fixed and/or replaced.
-
@mallard said:
VB.Net is an alternative syntax to C# designed (IMHO) to allow programmers to more easily transition from VB6 to C#.
Perhaps C# was written to lure C++ programmers closer to the dark side? Hmm... VB.NET wasn't written to bring us all together. CLR was. If VB.NET was considered transitional, they wouldnt be currently developing 'VB9'.
The real reason why VB.NET, C# and C++ exist in MS's world, is quite simply because thats how they can target the largest number of developers, and their favoured languages. I.E more $$$$ for MS.
@mallard said:
If VB.Net was the same language, then porting applications from VB6 to VB.Net would require changes, but not a complete rewrite.
If VB.NET was a different language, then VB6 programmers would have as much difficulty learning it as they would C++/CLI. But they dont. It maintains much of the same syntax as VB6, the real learning curve being the framework.
@mallard said:
It's not that they broke compatibility......
The reason why porting is so time consuming is because MS broke compatibility. Some would say that if breaking changes are inevitable then they should come sooner rather than later.
@mallard said:
......it's that they replaced it with a language that isn't "VB7" no matter what they called it internally.VB6 was a language that could trace it's ancestory all the way back to GWBASIC....
Windows XP still gets called "Windows" even though its source code would barely resemble the original. It doenst make it any less of a descendant.
If it looks like a duck, smells like a duck and feels like a duck.......then it is a duck. Unless option strict is on...
-
@Jeff S said:
@mallard said:
@Jeff S said:
@mallard said:
I consider VB.Net to be an entirely new language. So "VB" has not stopped doing that and probably never will, unless MS decide to introduce a new version.
hmm... interesting. They "fixed" VB by removing all the old syntax, cleaned up the language, and released it as VB.NET. Yet, because of this, you have decided, this is no longer VB and not an upgrade of VB.
Yet, at the same time, you are saying that the "real" VB will never be "fixed" unless they release a new version .... You do realize that in order to "fix" the "real" VB, they will have to break compatability with older versions, right?
think about that a little bit.
It's not that they broke compatibility, it's that they replaced it with a language that isn't "VB7" no matter what they called it internally. VB6 was a language that could trace it's ancestory all the way back to GWBASIC. It was a quasi-object-oriented language for writing Win32 applications.
If VB.Net was the same language, then porting applications from VB6 to VB.Net would require changes, but not a complete rewrite. For any non-trivial application, porting to VB.Net does require a complete rewrite. Features only fairly recently introduced, such as usercontrols, have been dropped.
VB.Net is an alternative syntax to C# designed (IMHO) to allow programmers to more easily transition from VB6 to C#.
So, basically, you reserve the right to always complain about VB -- no matter what Microsoft does.... Since VB.NET is a new language in your mind, it doesn't solve any of VB's problems. So, you ignore VB.NET and all of it's merits when discussing VB. And if they did release a new version of VB that does solve those problems, by definition it will not be backwards compatable since many of those things we complain about (error handling, type checking, quasi-OOP model, weird syntax of old BASIC commands, hard-coded "commands" in the language instead of class libraries, the old "ruby" form model, etc) will be removed, fixed and/or replaced.
VB.Net does fix some of VB6's problems, but in the same way that Java fixes some of C++'s problems. Ie by starting again from scratch.
If every time you were supposed to fix bugs in your software, you rewrote it, using a different file format, menu structure and workflow, then advertised it as a seemless upgrade, do you think your customers would be very happy? Do you think that they would actually upgrade, especially if there were no way to upgrade their data files without losing most of the data?
-
@JimboJones said:
@mallard said:
VB.Net is an alternative syntax to C# designed (IMHO) to allow programmers to more easily transition from VB6 to C#.
Perhaps C# was written to lure C++ programmers closer to the dark side? Hmm... VB.NET wasn't written to bring us all together. CLR was. If VB.NET was considered transitional, they wouldnt be currently developing 'VB9'.
The real reason why VB.NET, C# and C++ exist in MS's world, is quite simply because thats how they can target the largest number of developers, and their favoured languages. I.E more $$$$ for MS.
@mallard said:
If VB.Net was the same language, then porting applications from VB6 to VB.Net would require changes, but not a complete rewrite.
If VB.NET was a different language, then VB6 programmers would have as much difficulty learning it as they would C++/CLI. But they dont. It maintains much of the same syntax as VB6, the real learning curve being the framework.
Much of Java's syntax is the same as C++'s, does that mean that they are the same language?
Java and C# are even closer, are they the same language?
@JimboJones said:
@mallard said:
It's not that they broke compatibility......
The reason why porting is so time consuming is because MS broke compatibility. Some would say that if breaking changes are inevitable then they should come sooner rather than later.
@mallard said:
......it's that they replaced it with a language that isn't "VB7" no matter what they called it internally.VB6 was a language that could trace it's ancestory all the way back to GWBASIC....
Windows XP still gets called "Windows" even though its source code would barely resemble the original. It doenst make it any less of a descendant.
Windows XP is an NT derivative and was advertised as such. It is not a decendant of the original Windows 1.0, nobody says that it is. But some people claim that VB.Net is a decendant of VB6 when it is at best a distant cousin.
@JimboJones said:
If it looks like a duck, smells like a duck and feels like a duck.......then it is a duck. Unless option strict is on...
-
Ahem, I think a more likely interview would go like this:
Edgar's Consturction Company: Hmmm...Mr.
Midriff, we see from your resume that at your last job, you had to hammer nails into concrete with your penis. Can you explain why?
Mr. Midriff: Well, my
primary duty there was to hammer nails. My employer believed that using our penises was the best way to implement a world-class enterprise-wide nails-in-concrete system.
ECC: But, why, in the name of god, would you use your penis?
M: I was only following orders!!!
etc.
-
VB.Net is really just a major change from VB6. I spent two weeks to "upgrade" a 5kloc project from VB6 to VB.Net. The process was simple: Run the crappy upgrade wizard (which generated 1523 errors), and fix all of the bugs.
-
@UncleMidriff said:
Edgar's Consturction Company: Hmmm...Mr. Midriff, we see from your resume that you primarily used a screwdriver at your last job. Can you explain why?
Mr. Midriff: Well, my primary duty there was to turn screws. A screwdriver, provided to me by the employer, seemed the best tool for the job.
ECC: But we hate screwdrivers. We use hammers here, only hammers.
M: Oh, I see. Well, as you can see from my resume, I've plenty of experience using hammers as well.
ECC: Smirks Right. But, you used a screwdriver...would you have us believe that any construction worker worth hiring would use a screwdriver?
M: Well...ummm...well yes, if that's what his employers require of him. Plus, the screwdriver really is the tool for the job of turning screws.
ECC: ...
M: ...I mean, sure, you could pound in a screw with a hammer, but I can hardly see why you'd want to do that, especially if, as in my case, your employer provides you with a perfectly capable screwdriver.
ECC: "Perfectly capable screwdriver!" Heh, that's a good one.
M: ...
ECC: ahem Well, Mr. Midriff, we certainly appreciate your time, but we're afraid you're not quite what we're looking for.
M: Oh. Well, I uh...
ECC: We're looking for construction worker of a higher caliber, not one who would use a screwdriver.
M: ...
...continued
ECC: mumblewhispersnicker
M: What?! I heard that! That's just absurd! I never once said I would try to hammer in nails with screwdrivers! All I was trying to do was to explain to you why I used a screwdriver at my last job. My previous employer wanted me to use screwdrivers to turn screws, and since that sounds pretty reasonable to me, that's what I did. You people want someone to hammer nails and that's fantastic, I can do that, just like my resume says.
ECC: But Mr. Midriff, surely you can understand that we don't want to hire someone who thinks bashing nails in with a screwdriver is acceptable.
M: ...
ECC: So, you understand where we're coming from here...
