|
When I was in high school, some wizard wrote a Fortran program nicknamed The Black Death. It entered an infinite loop that printed solid lines of asterisks.
It was soon outdone by The White Death, which entered an infinite loop that "printed" form feeds.
|
|
|
|
|
I worked in IBM for a few years, and once, dispatch got a call to hurry up and come fix their printer, because it was having a carriage runaway, and it was already on its second box!
|
|
|
|
|
My favorite was a program that recursively created a bunch of folders with names borrowing characters from the extended ASCII set in the user's home folder. That was back in the Novell Netware days, working on DOS, so you couldn't easily batch-delete folders.
I just left the program in my share (everybody's folders were public to everyone). I wanted to prove that idiots will run unknown EXEs from unknown folders...and they did not disappoint. Eventually the admin got tired of calling out people asking why they had a bunch of non-sense folders eating up his disk space.
|
|
|
|
|
Yes, and we still light candles when the lights go out.
|
|
|
|
|
VB.NET, C#.NET, and C++.NET all generate the same MSIL assembly. So it is just down to the language preference at this point as the net result is 100% identical in speed and in most cases in program structure. C++.NET is quiet interesting though as it also allows STL containers to be used.
|
|
|
|
|
Well, C# allows a few things which VB doesn't.
|
|
|
|
|
And VB has On Error Resume Next which is a damn good reason for killing it! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I never had a problem with that as long as you did strict error checking until you turned it off with:
On Error Goto 0
|
|
|
|
|
When you have a series of
try { dosomething() } catch {}
statements in a row then on error resume next is a wonderful syntactic sugar to clean up your code. And yes, there are places where this syntax is appropriate.
|
|
|
|
|
That syntax is never appropriate, because you are swallowing exceptions and have no way to find out they occurred, much less what might have caused them.
At the very least, log the error detail before you swallow it - but then it wouldn't be On Error Resume Next, would it ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: is never appropriate
Uh, no. But there should be a comment to state that it is appropriate for that code.
Some of what I'm doing now is ignoring Exceptions because that's what works best.
Just yesterday I wrote:
try
{
this.buffer.Append ( Char ) ;
}
catch ( System.ArgumentOutOfRangeException )
{
}
Which allows the caller to provide a limit to how many characters are allowed in the StringBuilder as appropriate.
Yes, this is not a catch-all, but I have those as well as appropriate.
|
|
|
|
|
And what you are doing is not On Error Resume Next either: you are ignoring a specific error, and marking why in the code. I do the same under some circumstances.
That's not the same as a blanket "Ignore all errors from now on", or putting try...catch() around each line of code!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: have no way to find out they occurred
not true, in code with "on error resume next" you can check err.number to see if it is non zero after every statement if you want and also access the error description
you can then clear the error (err.clear) and carry on
it is a useful tool if used properly
|
|
|
|
|
I was literally reading to see that someone added this.
This is EXACTLY true, and the right way to proceed. in fact, in debugging, we would paste in a block to help us iterate out and determine which errors to trap! It wasn't always 5... LOL
|
|
|
|
|
VB is still far better at parsing stringly typed data sets than any other language. The C* functions in VB hide hundreds of lines of code complexity for parsing strings into fundamental data types.
|
|
|
|
|
Probably not something I would use.
In my opinion, the one thing VB does better than C# is how Extension Methods are defined.
|
|
|
|
|
Agreed. VB wasn't perfect for ~everything~ but it was Rapid Application Development at its best. The massive simplification of otherwise gangly code with all of it's built in functions is what made it so friggin' popular. VB6 was the most used programming language on the planet when MS pulled the plug and VB.NET was in the top 3 when MS just started drifting away from supporting it. Amazing how you can have a product so popular and just chuck it...twice. Dumping the language like that is what makes me not trust investing time learning and collecting code for anything proprietary to MS. No customer loyalty.
|
|
|
|
|
It's more down to the editors and compilers supporting the language.
I could undoubtedly compile my own VB files and run them on .NET 6 (I'm assuming the resulting MSIL will run fine, but it isn't guaranteed as Microsoft seems to have dropped support).
However, Visual Studio doesn't support VB projects anymore, so I'd have to do it all manually, which is a pain, and not viable for a professional project.
And, as said, it's not VB.NET generating the MSIL, but the compiler, and when Microsoft drops support for that, it could be possible that VB.NET becomes incompatible with newer versions of the framework.
|
|
|
|
|
I have VS 2022 and it supports VB.
|
|
|
|
|
Visual Studio does support VB.Net - but it has never supported VB (Visual Basic 6, Visual Basic 5, etc.).
|
|
|
|
|
was it ever alive ? dat it da question.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Judging from the amount of VB code that's still around it was very much alive.
|
|
|
|
|
It pioneered component (vs object) oriented development; a pattern which is useful today.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Quote: It pioneered component (vs object) oriented development; a pattern which is useful today.
I'm pretty certain that it did not; unless my memory is failing me (and at this age that is very possible), components were part of the Windows tech stack since '92 (COM and/or OLE). VB, like other Windows programming language tools, could use them.
IOW, they were installed with Windows, not with VB. VB was just the most popular way of writing Windows programs for well over a decade.
|
|
|
|
|
Component-based "architecture" was about reuse; not "COM" or "OLE" in particular.
VB was popular because of drag and drop (components).
The "RecordSet" (a component) was fundamental to sane client-server development.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
