Printable View
I just took a look at New Posts and it's almost a complete sweep for VB6. I just don't get it. Can anybody explain why so many people, including newbies, are still using this relic of a former age years after MS dropped all support for it? I mean, nice as it is to be thought a radical at my advanced age, it just seems like commonsense to at least be in the right century programming wise. Are these people still running Windows 95, for goodness sake?
The reason for this is because VB6 is the closest thing to being a true BASIC. Even to this day, a lot of people get turned off by VB.Net cause of all the .NET commands they have to memorize, not to mention the This.That.This.That.DoSomething style of syntax, as well as switching to different configurations with the .NET versions just to get something working. Not too many people go for that. For some people, VB6 is much easier to learn than VB.NET. For others, its vise versa. Its why to this day worldwide, VB6 continues to be used to this very day. Even I still use VB6 a heck of a lot more than VB.Net, and I have Windows 7... mostly cause I feel Windows 8 sucks and don't feel its worth switching to unless I'm using a touch screen. But I'm using my computer from my couch with my 40" HDTV being my monitor and a wireless keyboard, with the laptop being hooked in using an HDMI cable, sooooo yeah. Anyways, I even written a fully functional Nintendo Emulator in VB6 (see my sig below.) I just get massive sized projects so much more done faster. Also codewise, VB6 can do things in one or two lines of code, whereas in VB.Net, its vise versa for other things. VB.Net (especially 2010) is also a massive memory hog, and tends to crash once in awhile....on my gaming laptop of all things! At least the Express edition. Can't imagine what it would do with a basic laptop. :ehh: However I haven't tested VB.Net 2012 yet. In my honest opinion, VB.Net is starting to look more and more like Java without the semicolons for every new version to come out. I understand .NET gurus will shoot my post down, but you guys gotta understand it from a 16 year VB6 user who used VB.Net for nearly a decade. To this day I feel VB6 is much much easier, even to learn programming in general.
Java without the semicolons would still be a good thing. Those semicolons are just there for frustrations sake.
Since you expect your comments to be shot down, I won't bother. I was a major fan of VB6 for many years. Certainly not 16, though, because once I got familiar with .NET I could never go back to that crappy IDE using a fairly crippled language. It did have the advantage of having a small runtime and a better package and deployment wizard if you were going to go with installation off media (which was your only built-in option in VB6).
The one thing I would note is that, for me, VS2010 (and 2005 and 2008, too) is VERY stable. Whatever crashes you are getting are probably worth looking into. I can't remember the last time 2010 crashed on me, and I generally use several instances every day (I currently have four instances open to work on four different projects in an interleaved, multi-tasking, way). I'm not so keen on 2012, though, but only because I find the screen appearance very Windows 3.1 (though I hear it is a variation on Apple, or some such, so maybe everybody sucks).
I respect you as an extremely knowledgeable and skilled programmer but that statement is just plain slanderous. It implies that VB6 has more terse methods of accomplishing certain tasks than VB.Net. Having experience in both languages I can tell you confidently that it is absolutely not true. Just about all common tasks in programming can be done in fewer lines using VB.Net than in VB6 especially when it comes to manipulating lists, arrays and collections.Quote:
Originally Posted by Jacob Roman
I know exactly what you mean. 2012 is brings some attractive language features but I just can't get past how ugly it is compared to 2010. And all those caps.....God! It drives me crazy.Quote:
Originally Posted by Shaggy Hiker
Thats what I just said. VB6 does this in one or two lines of code with some things. And VB.Net does things in one or two lines of code with other things. With the opposite language, it takes more code, and gets a little more complex to do such a simple task. Both have their advantages and weaknesses. VB.Net does great with manipulating lists, collections, and arrays with such little code, while vb6 it takes more. But vb.net takes more code to do simple graphics where in vb6 its literally just one line of code.Quote:
Originally Posted by Niya
I can speak to this as well. In VB6 I wrote quite a few controls which were implemented from scratch using GDI for drawing. I've also written controls from scratch in VB.Net. I can tell you that I'm far more productive in VB.Net when it comes to graphics.Quote:
Originally Posted by Jacob Roman
First of all, In VB6 I had to import all the GDI functions myself and secondly, I had to do a hell of a lot of constant-hunting. For example, AC_SRC_ALPHA for alphablending GDI functions. Then there's all the SelectObject calls, CreateCompatibleDc calls, not to mention you have to remember to delete these objects lest your program suffers from GDI leaks.
GDI+ in VB.Net was God-sent. I will be the first to say though, that it was a little painful moving from GDI which I had become intimately familiar with to .Net's object based GDI+ which seemed so alien to me but over time, as I learn it I realized just how much better organized it is in .Net. No longer did I have to hunt for API declarations for the most common graphics operations. No longer did I have to go slugging through C header files for constant values. No longer did I have to worry about all the tedious boiler plate associated with creating device contexts, bitmaps, brushes as well as the tedium of having to always remember to clean them up as the GC is a very competent safety net.
I'm sorry, but I find it much less painful to deal with graphics in VB.Net than VB6.
There are probably a few sources of new VB6 programmers that haven't been mentioned.
First you have those who got a taste using Office VBA, and second a lot of former QBasic/QuickBasic users are moving up to 64-bit Windows where you can't use it anymore. Both of these groups will probably take more comfort in VB than VB.Net because of the close family ties and similar code syntax.
The biggest puzzle to me is where they are obtaining legit copies of VB or VS 6.0 to work with.
I hadn't thought of that, which is odd, because that's the route I came to VB5, but I think you are probably right on the money with that.Quote:
Originally Posted by dilettante
How legit? I think I have a few copies lying around. It is probably still available through the MSDN subscription of the right level (though I haven't gone looking in a couple years).Quote:
The biggest puzzle to me is where they are obtaining legit copies of VB or VS 6.0 to work with.
I've noticed that and what seems to quite a few homework questions for VB 6.0 indicating it is still being taught to me. I just figured VB 6.0 is still pretty entrenched in the business world. Part of my thinking might be influenced coming from a mainframe COBOL background. As great as the "new stuff" was it just wasn't cost effective to rewrite everything. Mainframe COBOL systems written in the eighties are still running in some places I know of. The legacy systems I support now are still VB 6.0 They are still generating money so why rewrite them just to be "in vogue". There is still a business world out there that looks at cost benefits. Just rewriting systems that work and generate money just to do it doesn't make sense. On the flip side nothing new we are doing is being done in VB 6.0.Quote:
Originally Posted by dunfiddlin
I thought Microsoft was supporting the runtimes through Windows 8?
Is it so that you can see the traffic behind you?Quote:
Originally Posted by dunfiddlin
There are many companies out there still running VB6 apps that balk at the cost of converting to .NET and will resist doing so until they no longer can.
A couple of years ago I took a contract job with a company that wanted to rewrite a whole mess of VB6 apps in .NET but after getting about 1/3 of the way through the job upper management lost patience, fired most of us and the rest (including me) were told we would now be responsible for maintaining and supporting all those VB6 apps. One by one we all left for other opportunities and that company has ever since been running constant local ads looking for "experienced VB6 developers."
Nah.....I think his concerned is about the Jewish powers that be, which are promoting in ever so subtle ways, that we all should stick with VB6. Its part of their plan for world domination. They get us to stay in VB6 and they when everything starts to break down, they come in with VB.Net to clean up the mess and makes lots of dough.Quote:
Originally Posted by Witis
What about the Asians, what do you think of them and could they be involved too???Quote:
Originally Posted by Niya
Oh come on. We all know its the Wiggers.Quote:
Originally Posted by Witis
Wait Wiggers......Witis.....I smell a conspiracy!
They're kind of stuck.Quote:
Originally Posted by homer13j
I do a bit of VB6 contract work and won't take on mantaining anyone's old stuff unless they will pay my regular rate.
The problem is that they want to pay entry level wages, probably because a lot of shops see maintenance programming as entry-level work in general. This will fend off any experienced programmer, who really doesn't want to be stuck doing nothing but maintenance work anyway - let alone for peanuts.
There is still new VB6 development going on, but of course year by year it gets thinner. And the average shop won't want to engage in it until they have to, usually once they have created a .Net monster and are dying from poor performance. But machines are powerful enough now that this only occurs in a few niches. .Net works well enough for almost everything that doesn't demand C++ anymore.
Conversions are often a nightmare, a big part of this stemming from poorly written code in the first place. There is far too much production VB6 code out there that was cobbled together by people for whom VB6 was their first programming language and who had no formal software development background. While it's expensive you're generally better off to rewrite from scratch
.NET, being truly Object Oriented, tends to lead people into the OO swamp. If you can avoid that, you can get better performance from .NET than from a similar VB6 program. I only have one good head-to-head comparison (and I don't even have that, anymore, because I can't find the old VB6 version of the program), but that one comparison was quite the comparison, as it took days to run without any user supervision.
On the other hand, I took over a project where I got to see how my predecessors were headed right into the swamp with enthusiasm and energy, as always seems to happen. Classes stacked on classes in arcane heirarchies that would eventually turn into an abysmal nightmare for maintenance.
What do you mean ? Can I assume you mean going crazy on inheritance and interfaces can impact performance ?Quote:
Originally Posted by Shaggy Hiker
They probably allied themselves with the Zionists the same way the Japanese allied with Hitler who was a secret Jew ;) :)Quote:
Originally Posted by Witis
Hmmm...you may be on to something here. :)Quote:
Originally Posted by Jacob Roman
Is that a Wigger -> http://www.youtube.com/watch?v=HJZPzQESq_0 ???Quote:
Originally Posted by Jacob Roman
I think I killed a few braincells watching that :lol:Quote:
Originally Posted by Witis
Yes, but mostly just the performance of the programmer.Quote:
Originally Posted by Niya
I've also seen a tendency to create towers of haphazard class hiercharchies. This is also a common disease among Java programmers, so I don't think it's about .Net so much as some programmers simply being undisciplined and "drunk on objects."
The scary part is that they also seem to entirely ignore one of the major legs propping OOP up: encapsulation. They disregard this and create these hierarchies with so many interdependencies that a change to one often requires changes to many others, ultimately increasing maintenance costs.
It also makes it very difficult to both write and to read developer documentation for these wumpus-hunt monstrosities, let alone to go spelunking through them without a guide at all.
Of course VB6 is OOPy enough to do the very same thing, but in that case you're more likely to deal with the opposite problem of too much interlinked static code. For some reason a lot of programmers who write VB6 fear and loathe the use of classes.
Then some move on to VB.Net and start crowing about the virtues of objects! This gets blamed on the language when the real culprit they fail to recognize is that their VB6 skills were immature.
Is there, by any chance, a one word term for Asians that springs to mind???Quote:
Originally Posted by Niya
U sure abt that mister???Quote:
Originally Posted by Niya
As I see it the inheritance argument and the poor OO performance argument are two different beasts.
OO will often perform worse than functionaly oriented code. This is because an object (unless static) needs to be constructed in it's entirety before it is used. It might have dozens of properties and methods that aren't actually relevant to the problem at hand but will be constructed in memory anyway. Functional code, on the other hand, tends to only load up the particular information it needs into memory. Oddly, inheritance and interfaces actually help alleviate this performance issue because they allow only "bits" of objects to be constructed (e.g. you may only construct a superclass if that's all that's required to solve a problem instead of having the overhead of creating all the sub class elements as well).
The inheritance nightmare is more about code maintenance than performance and I personally think it's often overstated. There is absolutely nothing wrong with deep and complex trees as long as they're well engineered and if you want to see example of this just look at the classes in the framework. Some of them are 9 or 10 levels deep but we all happily use them and even inherit from them without batting an eyelid and without complicating our own code. The reason is that we aproach them as a consumer. We know what we want them to deliver and we don't care how they deliver it or the depth of the inheritance tree that sits behind them. The whole of OOP should work on that principle. You don't care how an object does what it does, you just care what it does. Of course, that only works if the behaviour of the object doesn't change in some unexpected way but that's what techniques like unit testing are for.
The problems of overly-complex object trees is inherent in OO languages of all flavors. There was a fairly famous book on the subject back in the 90s regarding C++, and I think that the problem has a name, though I currently forget what it is. VB6 has a different, but related, problem where global variables can tie disparate routines into a total spaghetti mess (except that spaghetti is easier to untangle). Both problems are a result of poor or misguided practices, though the practices are somewhat different.
I liked the wumpus-hunt reference. I have a link to an online version of the old Hunt the Wumpus game on my system at home. It's an oddly easy game. I don't remember it being so easy when I was young, but I may not have been quite as logical in my approach.
@FD: I'm not sure that is true. In the 90s, there was a fair amount of discussion as to how you had to use C over C++ for cutting edge games because the added cost of OO was too much to bear. Compiler developers focused on this issue for several years, and by the time the first ANSI standard was coming out, it was generally held that the operating cost of OO had been reduced to 0 or near enough to 0 that even the cycle counters didn't seem to care anymore. After all, functions don't get replicated with each instance of an object, they only exist in memory once, and they are generally all loaded somewhere when the app starts. That leaves only data members, and those may be nearly the same for procedural languages. There was a cost for OO, I'm just not sure that it exists anymore.
You're probably right. My knowledge on the subject mostly comes from the 90s :)Quote:
There was a cost for OO, I'm just not sure that it exists anymore.
The thread is making me thirsty, time for some refreshments -> http://i64.photobucket.com/albums/h1...1/759fdc8c.jpg !
Now that was refreshing!
Next is a classic tune from the year Visual Basic 6.0 was realeased (1998) -> http://topmp3lyrics.com/lyrics/Nervo...al-Mix/5650345 !
Why is it that every time I see the title of this thread the song "So Macho" by Sinita pops into my head? Am I turning gay?
When I think about it, the only cost I can logically come up with is the cost of construction. With most class constructors containing no code I would expect the overall cost of OO would be low. However, there might be a penalty to pay when it comes to memory. Objects in most languages as far as I know need memory be to allocated on the heap and it needs this memory to be cleaned up eventually. Purely procedural languages like C have no such worries. Most of the memory being used would be stack memory for local variables and stack memory is pre-allocated. A stack pointer is simply incremented when more stack memory is needed and this is many thousands of times quicker than an actual allocation which requires many complex link-list operations on Windows and God knows how many other OSes. The only time there would be heap allocations is when the developer requests memory with something like malloc, but there are no natural language implements that need the heap allocations. With objects everywhere in OO languages, there would be a hell of a lot of heap allocations which will have an overall cost.Quote:
Originally Posted by Shaggy Hiker
I think this is what the performance issues about OO languages comes to.
[EDIT]
I forgot to mention the only implement in procedural languages that do use heap memory, global variables. However, they are set in stone at compile time which means they're allocated only once. Objects in programs built using OO languages on the other hand are constantly being allocated and de-allocated from the heap.
One other thing....Anyone that thinks that this is ammunition to fight the war against .Net should think again. Like stack memory, managed memory in .Net is pre-allocated and managed similarly. Stack memory is lightning fast because there are no actual allocations. A stack pointer is incremented in this pre-allocated memory. .Net's memory manager uses this same concept. When memory is requested, in most cases a pointer is simply returned to a block of free memory without any searching or look-ups. Now there are other considerations that have been taken into account that doesn't make managed memory operations as fast as stack operations all the time but managed memory allocation in .Net I'm willing to bet is many times faster than something like malloc, which is what C++ uses for its object allocation.
[CORRECTIONS]
Corrected: .Net's memory manager uses a very similar concept
To: .Net's memory manager uses this same concept
Corrected: When memory is requested, in most cases a pointer is returned to a block of free memory after a simple look-up.
To:When memory is requested, in most cases a pointer is simply returned to a block of free memory without any searching or look-ups.
From:something like malloc or new
To:something like malloc (There's no new operator in C as far as I know)
Continuing from my comments on .Net memory management:-
Here is a code project article that talks about how .Net manages memory.
In particular it says this:-
In other words, it works like stack allocation hence its very very fast.Quote:
Upon request of memory from a thread say, .NET allocates its memory from the shared Heap and moves its pointer to the next address location. This is in contrast to all other programming languages like C++ in which memory is allocated in linked lists directly managed by the Operating system, and each time memory requests is made by a process, Operating system searches for the big enough block. Still .NET win32 application has the limitation of maximum 2GB memory allocation for a single process.
There was another cost to OO, early on, though I believe it has been nearly removed. It's been a long time, but it had to do with the fact that the class had a look-up table for the functions, and that meant that there were a few extra cycles on every function call. This may have been amplified for inheritance, or may have only been true for inheritance, or something like that.
That's sounds more than a bit suse and completely crazy to me!!!Quote:
Originally Posted by FunkyDexter
Petaflopping is almost a certainty!!!Quote:
Originally Posted by FunkyDexter
I believe I know what you're talking about. I have a hazy recollection of reading an article years ago about virtual functions using look-ups in C++ or some such thing.Quote:
Originally Posted by Shaggy Hiker
Believe it or not, we still use VB3 in some places here, and it's causing us major problems. We're trying to upgrade to Windows 7 from XP, but of course that's not compatible with 16-bit VB3 applications.Quote:
Originally Posted by dunfiddlin
Yeah. I think they still do, but it's been nearly twenty years since I've paid any attention. Using a virtual table for looking up function addresses makes sense for inheritance. Something about that added a cost that made C++ unsuitable for cutting edge games. The design was subsequently improved to the point where the cost went to near zero, I think, but since then I have lost track of where it is at.
It should run on the 32 bit versions of Windows 7/8 without any dramas,Quote:
Originally Posted by InvisibleDuncan
otherwise try running 64 bit versions Windows 7 in XP mode (exception is that it doesn't work on home premium) -> http://windows.microsoft.com/en-AU/w...indows-xp-mode
It might even be as easy as right clicking the shortcut, selecting the compatibility tab, and setting the compatibility mode (untested)!
I just had seven!Quote:
Originally Posted by Witis
I knew you guys would tear me a new (....yeah....) on VB.Net. But heres the thing. Microsoft is starting to suck hard. And here are some reasons why:
1) They are already coming out with a game console, the XBox One, thats pretty much DOA because they turned it into an overglorified cable box. All they talked about during the revealing was TV TV TV, Sports Sports Sports, Call o Duty Call o Dooty Callodooty, and even more TV. They didnt focus on what the gamers wanted, or games in general for that matter. Majority of hardcore gamers could care less about sports. Were freaking nerds! And the whole point of buying a game console, is to play games! And with all the rumors gone viral, some of which is true, and due to the vague responses from MS, it will die on arrival because everyone will be flocking to Nintendos Wii U and Sonys PS4.
2) Windows 8 is a complete utter failure, and MS knows this. They blended a touch environment with the Windows OS that shouldnt even be in a regular PC unless you actually have a touch screen. They made it much more difficult to troubleshoot problems, and added a few more extra steps to simply shut down the computer. My girlfriend, her brother, and I are practically computer experts who know the ins and outs and can troubleshoot issues such as an internet disconnection, and we had a hell of a time trying to get it going on her mothers new computer which has Windows 8 when her internet disconnected on her. They also made it illegal to run programs on Windows 8 unless its purchesed from the Windows Market, as well as licensed by MS. Which means programs like Steam could be deemed illegal by Microsoft! And there are tons of other news articles out there showing a lot of bad signs about the new OS. There was even some news on the radio I heard that MS is allowing people who swtiched from Windows 7 to 8 to switch back to Windows 7 for a small fee, and the reason they allowed this is because a lot of consumers are very unhappy with the new OS, such as driver issues, hardware issues, etc. I mean I can go on and on. Windows 8 just sucks.
3) They arent listening to us consumers, and shoving crap down our throats for the sake of money cause they know were sheep, and well buy the next thing to come out of MS.
Bottom line is that I still use VB6 and will continue to use it. With all these problems I'm seeing with MS. I don't trust them as much as I use to. I don't like what MS did with BASIC turing it into VB.Net. I don't like VB.Net. I don't do OO programing. Hell 90% of the time I don't even use objects. So things such as inheritance is completely useless to me. And I personally do get a hell of a lot more done faster in VB6 than I ever have in VB.Net. With VB.Net I struggle doing the same exact project. And this is with me knowing what I'm doing. If you guys feel you are faster and better in VB.Net than in VB6, fine. But it all depends on the kind of programming. If you guys are like me who likes to do game related programming using DirectX, VB6 is my personal language to do that over VB.Net. Although I should be using C++, and I do once in awhile. Matter of fact I should use C++ a hell of a lot more often. I'd be just as good as the big boys who make games like Callodooty.
They may very well have thought that but they've caught two very heavy colds in W8 and Surface and been forced to backtrack on the former (the 'update' will look so much like W7 that it might as well be W7 by all accounts) and start throwing offers and giveaways at the latter. You can only get away with relying on a 'fanboy' base for so long and, in truth, that element has always been less of a factor for MS than others. You need a certain cultishness to keep the level of unthinking loyalty that Apple has commanded, for example. I think you can expect rumours of a major reorganisation of MS to become fact very soon. You can't buck the market for ever no matter how dominant your position is (or at least appears to be).Quote:
3) They arent listening to us consumers, and shoving crap down our throats for the sake of money cause they know were sheep, and well buy the next thing to come out of MS.