|
d@nish wrote: Oh I don't like it. Too much No typing.
FTFY 
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
Whenever I see var I have trouble dissociating it from the dreaded variant in the subject language, it still makes me shudder.
Some silly bugger used a GoTo in a stored proc the other day, the reaction was not pretty.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: Some silly bugger used a GoTo in a stored proc the other day,
Almost forgivable. We have some in our C# code.
|
|
|
|
|
Shirley that's VB.net, VB6 had the wonderful Option Explicit. Where I used to work it was hanging offence to not include that one.
|
|
|
|
|
Don't forget Option Base[^], just to mess with anyone who tries to understand your arrays.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
As I always say Pete a good programmer can write bad code in any language.
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
Thank God! For a moment I thought you'd lost your mind. Everyone knows MicroFocus Cobol is second to none. Which is why it figures prominently on my resume. 
/ravi
|
|
|
|
|
A short while ago (like one or two months ago) there was a TOP article here on CP explaining that VB6 is a great language that should come back. It got quite some upvotes too.
Just looked it up: Visual Basic 6.0: A giant more powerful than ever[^].
It even won VB article of the month.
I'm not saying it's a bad article, the author clearly put time and effort in it, and I refrained from voting. I WAS very surprised by the article and the amount of people agreeing with it though.
Thought you might have read it
|
|
|
|
|
What a bunch of crack smoking dullards!! I had to keep it kid sister safe...
|
|
|
|
|
I agree with you whole heartidly though 
|
|
|
|
|
We still have many VB6 code around here (mostly batch and client legacy apps). The main reason behind is that the .NET framework is not installed on standard end user PC images.
The signature is in building process.. Please wait...
|
|
|
|
|
Doesn't .Net framework come with OS these days?
|
|
|
|
|
Depends on each image you create. Our System Admins just uncheck the .NET Framework option during install..
The signature is in building process.. Please wait...
|
|
|
|
|
vonb wrote: Our System Admins just uncheck the .NET Framework option during install..
You should then combat that with ClickOnce's prerequisite installers...
|
|
|
|
|
Like COBOL, VB6 is here to stay. More than 50% of business transactions are processed with COBOL and VB6. Some claim 70% and 80%.
|
|
|
|
|
I realise I may get flamed for this, and I am mentally prepared for it, but VB6 was not as bad as people make it out to be. Sure it was not the best language for much of anything, but it is not as bad as people make it out to be. .NET was far worse, and I would even go as far as to say that C# is more shoddy than VB6 ever was or ever will be.
Now before the flaming starts hear me out. I personally would class VB6 as an intermediary language, sure there was a lot more managed libraries than C++ will ever have, but the amount of managed code in VB6 pales in comparison to the amount of managed code in .NET or C#. As someone who has dabbled briefly into cryptography, managed code is the single largest bane of any language you can name. Unmanaged code also prods the coder to pay a hell of a lot more attention to what they are doing, to make sure they get things right, because getting anything wrong can lead to catastrophic failure, particularly in languages that have even less managed code libraries than VB6.
So is VB6 the best language ever? No, but there are certainly a significant amount of more "modern" languages around that are significantly worse.
Sure you could write some unsafe code in VB6, but if you are any good at it, you can write "unsafe code" that does the job it was written for, does it correctly, and is faster than the "managed code".
In short, before anyone starts ranting about how bad a language is, learn the compiler properly, learn the loop holes, the does and the don't. You'll be happier, more productive code monkeys. When speed and accuracy is of prime importance to your application, unmanaged code is king. Quit with the hand holding that are managed libraries and learn to code properly.
|
|
|
|
|
Seems like you wrote that trying to attract a flame. For most things managed code is 'coding properly', particularly with an intelligent garbage collection algorithm and large memory spaces. C#/.Net applications get very close in speed to a correctly coded C++ equivalent. An environment where "getting anything wrong can lead to catastrophic failure" is not better.
|
|
|
|
|
No it's not better, but it does teach you to be better coders because you are paying a lot more attention to what you are doing as opposed to letting the managed code do it for you. In many instances the managed code is also slower, see my cryptography example. But I do agree with you that managed code does suit most instances. I was being very specific with the example.
|
|
|
|
|
|
I see VB6 as an intermediary language, it's not as flexible as C or C++ , but in some instances it is superior to more modern languages such as C# because it does not enforce "best practices". Case in point is the following rant.
If you implement AES in VB6, using best coding practices, such as all local variables and the like, it is something along the lines of 45-50% slower than if it was implemented in C.
If however you implemented AES using code that does not fit "best coding practices", hand coding most things rather than using managed code, or doing things such as declaring all the variables as either global or static, you will notice that the VB6 code runs considerably faster, to the tune of 5-10% slower than if it were implemented in C.
There are 2 reasons for this. 1) VB6 is not ideal for cryptographic protocols, and 2) allocation of memory and then de-allocating it after you have finished running through a sub takes time, ok sure it's only a few microseconds, but when you are running through those subs several thousand times when encrypting a large file, you will definitely notice a significant difference in speed, even when compiled. The more computationally intensive those subs are, the worse the lag becomes. Point 2 is basic comp-sci. Having variables declared globally or as a static means the memory is allocated once, and is not released until the application has finished doing what it is doing.
Two of the core requirements in any cryptographic system is speed, and having the smallest memory footprint as possible so it can be used in multiple places, such as embedded systems or even smart cards which have an absolute minimum amount of resources available to it. You can have the most secure system in the world, but if it has a large footprint, you are limiting it's use. And if it's to slow no one will use it at all. So you have to make some compromises in your code to get that speed and minimal footprint.
The prime compromise is using code that is considered bad by most application developers. Bypassing most of the managed code, and hand tuning things yourself, and using intensely small subs, the more complex the sub the slower it will run. Even something as simple as turning off intrinsic compiler based error checking will effect the speed and footprint of your code.
Of course, using techniques that are not "best practice" can lead to catastrophic failure of the program in question, or the whole system if you are using a language that is capable of such a thing such as C. That is exactly why I made the statement of "it prods developers to pay a lot more attention" knowing where exactly a variable is being used, how it is being used, and when/if it can be reused. Without that close attention to detail, you're screwed. It goes back to the days when you had maybe one compile a week, when there was no real garbage collection, and resources were at a premium, so you must ensure that your code is pretty damn near spotless, particularly if you are writing code that is going to be used on a myriad of systems, where the resources available to that system is largely unknown.
Sadly most modern languages take away from the skill of the coder, because they rely to heavily on managed code that the coder can't see. Ok sure they know use this library and this happens, but they don't know how it happens, or wether it can be tweaked to get more speed or a smaller footprint.
This is why I, and most who have dabbled in cryptography on any serious level, prefer older languages that are not so polished, it makes for not only better coders, but better developers. Don't confuse the two, they are not one and the same.
I'll use an API that is in both VB6 and VB.NET to illustrate my case. The API is called copymemory, which exists in both VB6 and .NET, and is used in completely different ways in both languages.
In VB6 it is used in the following way:
copymemory(64, var1, var2)
What this does is takes 64 bytes from var2 and puts them in var1.
It is considered unsafe coding, but is significantly faster than an assignment which you will notice if you are writing code that is being called several thousand times before the application has completed, and using copymemory in .NET can't even do the required action properly.
So to close I will reiterate my initial statement. I see VB6 as an intermediary language, it's not as flexible as C or C++ , but in some instances it is superior to more modern languages because it does not enforce "best practices".
Now you go have a look at those code examples, how much of it fits "best application code practice" I'll wager that a large portion doesn't. Comparing application coding and cryptographic coding is like comparing oranges with mandarins, the only similarity is that they are both citrus fruits.
|
|
|
|
|
There was a time when it was a cool language, and I have made quite a bit money writing VB6 Applications. So I can't complain.
And on the other hand after using it for few years and earning money, I failed to understand that why my university taught me C++, or why we even need it. But then C# happen...
|
|
|
|
|
When C# happened to me, I still preferred VB6. 
modified 31-Mar-14 20:35pm.
|
|
|
|
|
d@nish wrote: No. It is not. Just kidding.
You must be VB programmer! April Fool's day isn't until tomorrow.
Marc
|
|
|
|
|
I am a VB6 programmer and I hate when people do not make the difference between VB6 programmers and other VB programmers. What it is so funny regarding this post ?! care to explain ?!
|
|
|
|
|
ISpliter wrote: What it is so funny regarding this post ?! care to explain ?!
People in the past have made "VB[x] is the best programming language ever" in jest. I thought it was funny that you made such a post the day before April Fool's Day.
ISpliter wrote: I am a VB6 programmer and I hate when people do not make the difference between VB6 programmers and other VB programmers.
Uh...Isn't VB6 totally outdated?
From wikipedia: All versions of the Visual Basic development environment from 1.0 to 6.0 are now retired and unsupported by Microsoft.
Marc
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
