Slashdot Mirror
Why Visual Basic 6 Still Thrives
theodp writes "Microsoft recently extended 'It Just Works' compatibility for Visual Basic 6 applications through the full lifetime of Windows 8, so VB6 apps will have at least 24 years of supported lifetime (VB6 shipped in '98). So why has VB6, 'the un-killable cockroach' in the Windows ecosystem, managed to thrive? 'Cockroaches are successful because they're simple,' explains David S. Platt. 'They do what they need to do for their ecological niche and no more. Visual Basic 6 did what its creators intended for its market niche: enable very rapid development of limited programs by programmers of lesser experience.' But when Microsoft proudly trotted out VB.NET, the 'full-fledged language' designed to turn VB6 'bus drivers' into 'fighter pilots,' they got a surprise. 'Almost all Visual Basic 6 programmers were content with what Visual Basic 6 did,' explains Platt. 'They were happy to be bus drivers: to leave the office at 5 p.m. (or 4:30 p.m. on a really nice day) instead of working until midnight; to play with their families on weekends instead of trudging back to the office; to sleep with their spouses instead of pulling another coding all-nighter and eating cold pizza for breakfast. They didn't lament the lack of operator overloading or polymorphism in Visual Basic 6, so they didn't say much.'"
I'm one of them. I still actively use it today. I know how to use it, and I never had any interest in learning .Net. I've got several mission-critical apps written in VB6, and I'm updating one of them right now. We have no plans to move to something else. If it ain't broke...
I don't respond to AC's.
A "just works" version of Windows, that MS sold support for, marketed toward businesses, that just stayed the same forever. As it is, MS makes its money on new versions. That's fine for MS, but bad for businesses that don't want to upgrade every four - six years. If MS made money selling a business copy of windows and then got a fair amount for support and updates on it perpetually, it would be win/win for businesses, developers, and MS.
Where I work at, we installed new systems in police stations in the last two years that were brand new and had Windows XP on them, because the software at the time didn't have Windows 7 drivers.
Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
If you had VB5 and you got VB6 you could upgrade your app to a vb6 application very quickly and your program looked and worked just like it did before. .NET breaks all but the most basic application, and there is a lot of rework to be done. Often these VB6 apps are not the best design and, and you need to find a .NET compatible version of your third party tools, then they are probably quite different and you need to rework them again.
Upgrading you VB6 app into
Next you have the .NET framework. I write a program in visual studios 2010, Now I need to make decisions... Do I compile it for .net 2.0 and not have as many features but know that my system will work on most modern windows systems, or work on 4.5 and require all the users to upgrade their system? Why can't I just compile it into a static .EXE
Finally you have older developers. These guys are not Computer Scientists, They studied other fields and happened to learn computers, and started to program before a lot of the formalization in good form came into place. .NET seems unnecessarily restrictive to them. Why do you need to type all this extra crap. I need it to do this, why do I need System.Windows.Forms.PotatoGun.PopSound() instead of PlayPop Often these older developers are just maintaining the existing system that they have coded decades ago. So there is no real push to upgrade and give them a new project just because it needs to support .NET
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Everyone involved with software development these days has surely heard of Ruby, and especially Ruby on Rails. Along with Cloud Computing and NoSQL, it was one of the most-hyped technologies of the past decade.
One of its core strengths is that it was supposed to allow relatively unskilled computer users to quickly create web apps. Much of the "hard work" was to be handled by Rails, including data access and the routing of web requests. In many ways, Ruby on Rails was claimed to be the Visual Basic of web development.
Unlike Visual Basic, however, we are seeing people fleeing from Ruby on Rails as fast as they can.
If I had to make a guess, I think it would be because of some of Rail's major problems. These include:
- it can be very slow
- it often doesn't scale well
- Ruby code quickly becomes unmaintainable, especially for large web apps, because it's a dynamically typed, interpreted language
- the community has archaic attitudes toward women
- people paying good money for web apps are quickly getting tired of the failed promises and shoddy work of so many Rails advocates and developers
While Visual Basic 6 apps usually aren't known for having the best or the most maintainable code, at least it doesn't bring along the numerous other problems that we see associated with Ruby on Rails. Perhaps this is why Visual Basic 6 has had some significant staying power, while Ruby on Rails is stagnating.
.NET is actually awesome, especially when used with C#. Java is too much bloat and slow and needs to die. But .NET is awesome and targets all PC, XBOX360 and Windows Phone 7. And you can use the best IDE on the planet, Visual Studio, to develop.
Less time that is; there's always a temptation to try and utilize all the bells and whistles in a programming language. Often this adds to complexity and makes the code harder to understand in one glance; polymorphism for example sucks if you only have sourcecode to figure out what's going on. I personally like C++, but I try to only use the parts which make life easier (and honestly stl for the most part is one of them, with a little study the basic stuff there goes a long way).
So much troll, so few words.
while(1) attack(People.Sandy);
There are many projects, usually internal or niche market applications, which have decades of legacy code to keep the product running. This is not a choice of the developers or done out of laziness, this is what their employers have given them to work with.
If you have to rewrite vast amounts of code because the programming language is out dated, you will find that depending on the size of the project, the company who owns the project will be on the hook for millions of dollars to rewrite it so that it will work with modern environment.
If you are a company in placed in this position of having to rewrite everything, what is there to say that you are going to stay on the Microsoft ecosystem. You have emerging technologies in the enterprise (iOS/iPad/Objective-C), you have Web Applications and "Cloud Computing" (Which are platform independent and would most likely run on a non-Microsoft backend) and if you are a developer who just wants to get it working on the cheap (Where the market is vertical enough that the customer will use any platform you tell them to because they need to run your app) you could probably save a tonne of development cash by just making it run on WINE on GNU/Linux
Better for Microsoft to keep supporting developers who have their ecosystem running on Windows, as these applications directly translate into sales of Windows licenses. If Windows did not have compatibility, then Windows will be just like the rest.
Incidentally, this is why Windows on ARM Tablets will ultimately fail, as there is no compatibility with x86 apps unless it is 100% written in .NET or HTML5 (not that many out there in the whole Windows ecosystem).
Because you can make a GUI using Visual Basic and see if you can track an IP address.
VB6 is simple, but there is a surprisingly large amount of power to be tapped from it, if you understand the underlying infrastructure.
Having done some hard core COM programming 10 years ago, for a Computer Based Testing "test driver", our team learned we could spend 2 days to get up a "ActiveDoc" in C++ using ATL, and WTL, or we could do the same thing in VB6 within an hour. Considering how fast it was to implement ActiveDocument and custom COM interfaces, I changed my mind on how weak I perceived VB6 was. (Unfortunately many of the VB trained, customer-based implementors of our interface were not as astute, and even in a VB6 environment didn't understand what they needed to do to create a component that would properly talk to the rest of our system.)
Still, knowing how quickly VB6 would let one get up an interface, I was able to help a room mate of mine create a level editor for our own rolled version of Zelda. It was a little cumbersome to learn how to read individual bytes of the palette based sprite files, but VB6 had all the power there.
All that said, VB6 should die IMHO. After (C# / VB).NET came out, it became a lot easier to make object dynamically talk to each other and perform byte level manipulation.
.NET thrive is because the Visual Studio IDE demands it, unless you are doing C++. The basic rule of thumb, if you are going to be writing programs for windows you use Visual Studio. Now .NET as a language isn't that bad, I actually like it. What I hate is the Virtual Machine nonsense, that only works on Windows Systems, yet it is still virtualized so it runs slow. It combines the worst attributes of the VB6 world and the Java World. If Visual Studio gave people a non .NET option for VB (a VB 7 per say) then I would expect VB 6 dyeing out and .NET wouldn't have caught on. It would have been an other J++
Java success is in the fact you can write code and run it nearly every modern system out there. And you code isn't scripted but in a way that can be closed source (Not all developers want their code Open Source) Also Java has a good set of quality IDEs Netbeans, Eclipse are a few of them, and they are really good at Java Coding.
Why do we want VB6 to die more then the others?
1. It is a platform for unstable applications. VB6 Apps have a tendencies of getting corrupted and random deaths where you need to reinstall them.
2. Visual Studio 6 needs to run on Newer OS's Windows 7 64 bit... Windows 8?
3. You cannot buy the media/licenses directly anymore. If you are going to grow you company you cannot stick on a tool where you cannot get legal licenses as your company grows.
4. Young Whipper Snappers don't want to use it. (We are at a point where we have a lot of software developers retiring) And we need to replace them with younger blood. The problem is the young guys do not want to use it.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I've been talking about this for years, and I've even been laughed at here on Slashdot for suggesting classical VB will never be going away. How could it? There is that lovely fully object oriented thingy called VB.Net? Why wouldn't you want to rewrite all your applications in it for no appreciable benefit whatsoever?
.Net that you could compile VB code into, but it's all too late for that now.
.Net applications and no one gives a flying fsck about Metro applications that Microsoft wants you to rewrite everything in...............AGAIN just so they can piss about with trying to amount to something on mobiles. Seriously Microsoft, no one gives a shit. Windows is a legacy application shell and nothing more.
The fact is that Visual Basic was and is used for what it was good at. Departmental and business applications where the overhead of that object oriented nonsense didn't make any sense at all. The fatal mistake that Microsoft made with VB.Net is that it was completely backwards incompatible (yes it is, and no, don't give me any of that 'compatibility' nonsense. It doesn't work, hence this article). You couldn't take a VB6 application, make a couple of changes and recompile it as you'd always been able to do. What they should have done was built a RAD environment on top of
Put simply, if Windows 8 couldn't run classical VB/COM applications no one, and I mean no one, in business would ever consider upgrading to it. Windows up to version 7 would have been virtualised forever. No one cares about
This "bus driver" has a PhD in computer science and in my weaker days wrote code that still exists in various linux distros. i started a company 15 years ago with some vb apps and, guess what.. the vb6 apps still sell. over $4 million per year with my staff of 5. So, you know, call me a "bus driver", call it a "scripting language", and any other insults you want - I can take it. Or rather, I just wont care.
The VB6 compiler produced native code. Most of the sloth came from the runtime libraries, and most of that from string handling : rolling your own StringBuilder class fixes most of that.
Java has the same issues, also using an immutable string class, but they fixed it by hacking the compiler to recognise where you are doing string concatenation in a loop and make a StringBuilder out of it instead. .NET also produces native code, eventually.
Performance problems in any of them are usually down to bad algorithms, or using a mass of bloaty libraries to compensate for a lack of time.
This is why when I develop applications with VB6, if I'm not satisfied with the speed, I typically use ASM as a back engine, and have the main interface and said engine communicate back and forth via commandlines and/or files. It might not be the most elegant solution, but it works in terms of stability and usability.
I'm not surprised it gets modded as 'troll' on Facebook
Not sure if trolling or just idiot. Either is pretty lame.
My VB6 devkit includes a whole bunch of stuff that make it tolerable ; one of them is a mousewheel plugin for the IDE. Also a text search that searches everything and supports regex, a "find all callers" routine, error handler insertion, and a decent stack-ish error handling library. Full stack traces with line numbers in VB6 code are very useful.
I tried to install it on Windows 7 and it didn't work. So i gave up (programming for windows)
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
It's built in to Excel. We use it all the time to generate C code from massive tables of translation and configuration data.
I'd prefer lisp. I could do it through COM links or whatever the kids call it nowadays but it works and is convenient.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
The company I work for has a well-staffed IT shop, but the one thing we are lacking is anyone with real developer experience. We have one woman there who is known as the "database developer", but all her experience comes from Access. Access front-ends to SQL databases, that sort of thing. It works for the most part, but it's frustrating from our perspective when we have to deal with all these Access databases/front ends, and we know things could be so much better.
A few times they've tried to send her to VB training of various kinds, and as the resident SQL "expert" and the one that works most closely with her, I've tried to steer her in the right direction. She's willing, but it's clear at this point she just doesn't have the skillset required to make the leap to "real" developer. This is a state job, however, so just letting someone go for such reasons is a convoluted enough process that it's probably not going to happen so long as she continues to be competent in the Access world she's created for us.
I'm damn tempted to see if I can get a copy of VB6 from MSDN or some other source and throw it in front of her, see what happens. I've got 0 VB experience myself, but from reading the descriptions it does seem like she might be able to embrace it. I've seen the behind the scenes coding/scripting she writes in these Access front-ends, and it really seems like she is doing a lot of what Visual Basic would require, but she just can't retrain her brain to deal with VB10 or whatever.
Is this a mistake? Our needs aren't anything special, just "Go get this SQL data and show it to the user, maybe let them edit it" type stuff. If I had any kind of time I know I could probably teach myself enough VB to do this, and I've been tempted a couple times just to pad the old resume, but it always gets put into the "Yeah, someday" file.
Any language that uses a newline as a statement terminator is demented.
VB6 won't die because the tool is geared to answer the problem "how do I get people to develop applications to solve problems themselves" and not "how do I make professional developers more productive and happy". VB6 solves a very broad problem whereas most other computer languages, IDEs and frameworks are geared for those who program for a living. And unfortunately, there really is no alternative. The fact that there are a lot of programmers today who grew into the profession who weren't programmers initially is not the point. VB6 is a tool that empowers a much wider audience to do their own thing than do "modern" programming languages.
VB.NET is more of a computer language that was wrapped around the .NET framework to try to "wean" VB programmers off of VB6. It won't work. You don't "get" what VB6 does for people if you think that. And it seems Microsoft simply doesn't get it either.
Does VB work under Wine?
Develop under Linux, deploy on Windows. ;-)
I taught myself VB6 (fool for a teacher?) about ten years ago mainly so I could write small apps and utilites for myself. Combined with Win32 api calls, it's been powerful enough for almost everything I've needed to do. True, my code isn't elegant but it gets the job done.
For a more modern object oriented language I think Lazarus (an open source Delphi clone) is in the same category as VB6. I found it easy to move from VB6 to Lazarus since the IDEs are similar. Lazarus is based on Pascal so some might consider it inelegant but it too gets the job done and the cost sure is right.
I am not sure the stereotypes Platt is describing really make sense. I know plenty of non-vb6 coders who work 40 hour weeks and actively avoid jobs where they must work evenings and weekends (myself included). I would imagine that plenty of vb6 programmers started working these kinds of hours after the .com bubble popped, for fear of losing their jobs otherwise (until they burned out, of course).
A career in tech is bad enough as it is....no opportunity for upward mobility without shifting to a completely different role that requires a completely different set of skills and training....a tight ceiling on the salary....spending most of your day typing on a computer rather than socializing...and so on. Working long hours without at least collecting overtime pay for them just adds injury to insult.
The only reasons I can imagine that people put up with that are:
1) you are programming games or something and as such really enjoy the work, and would work such crazy hours on your hobby projects completely unpaid if you could
2) You are making half a million a year (or more)
3) you are easy to bully and don't have any social skills (hence no social life) and no sense of your actual market value, so you let yourself be exploited.
I can't imagine that the majority of software developers fall into these categories. They simply must be the minority. Or am I just being totally egocentric and ignorant here?
3, and 4 are fair points. 1 and 2 are just wrong. VB6 apps are no worse than any other, and you can run VB6 on windows 7 64bit with a patch that you can download from MS.
I do think that VB7 would have killed .NET dead, which is exactly why they didn't make one. I understand MS wanted the original .NET to be much more VB compatible, but the .NET guys didn't (or rather couldn't) want to do this, they wanted to make their own version of Java and nothing was going to stop them. Well, until today when MS has realised .NET performance and efficiency is crap and they need to go back to native code. Maybe now they'll make a VB7 that is geared toward quick-n-easy Metro apps, then Windows8 might actually become popular.
Java itself is a simple and clean language, and is not that bloated by current standards.
I think it gets a bad rap, because people think 'applets', or 'J2EE', or worse yet, the countless piles of crap foisted upon them at work, known as 'enterprise software'.
The objective reality, I think, is quite different from often-mistaken perception -- I've seen both garbage and masterpieces written in everything from Ruby, to VB6, to Java, to Perl. Depends on the programmer, not the tools or languages.
It is a platform for unstable applications. VB6 Apps have a tendencies of getting corrupted and random deaths where you need to reinstall them.
Been using it since release. This is total BS. It is very stable.
Visual Studio 6 needs to run on Newer OS's Windows 7 64 bit... Windows 8?
What? I'm still running it on Win XP, Server 2003, 2008, Vista, and 7. WTF?
I loved VB6 and beat it death. For knocking out a quick application it was hard to beat. I long left it behind (at least a decade ago) but when I started developing iOS apps a while back I was so disappointed with the interface builder that it made me angry; they obviously never understood the joys of the VB6. I hate to say it but the whole interface builder was more of a rip off of the later c#.net interface in Visual Studio that drove me away from all things Microsoft. Thus in my present apps I don't use interface builder and just use all code building on things such as cocos2d.
.nets made the claim that you could do anything. But the reality was that every project seemed to follow the same cycle. 90% done in under a week and then the next two months was spent fighting with .net as you backtracked out of something it did poorly and then implemented it yourself.
As a side note I do love XCode and it seems that the non IB parts of XCode have been kept as separate from IB as possible so that people who want to ignore it can do so with ease.
While VB6 is and should be a historical artifact IDE builders could still learn a thing or two from it. Its key strentgh was that it seemed to know its weaknesses. It did what it did well and beyond that you had to instantly jump to lower level screen interfaces like GDI. Whereas the later
No, you're quite right. Most coders, even most of the extremely good and very productive ones, work the working week then go on to have some sort of a life outside work.
Working insane hours is acceptable for short bursts at crunch time. If it's consistently expected or needed then it's a management failure.
The objective is to spread FUD, taking advantage of a mass of lost, blind followers that had given up their theological believes to embrace a new, technological religion.
Java is not bloated, neither slow or sluggish or whatever. But your applications can be bloated, slow and sluggish if you hire bloated, slow and sluggish minded programmers to do the job. .NET is not better than anything, but it's not worst neither. The Object Model shines sometimes (Microsoft hired the guy behing Borlands's Object Pascal Windows Library). I would even consider a .NET career if it was not backed up by Microsoft - I'm already burned by Microsoft technologies twice, I can pass the third. =]
Ruby? Marvelous language. I loved every day I spent learning it. But I took Python to day to day business - I ended up more productive (and my services, less machine demanding) using Python. Nice API, by the way - but the lack of threading sucks.
I also made some good projects in VB6 and Perl also. I prefer not doing it again, however.
VB6 is, really, very limited on modern programming technics (but something can be done, nevertheless - I just think I can do it easier on another language).
Perl is too much different from anything else to make me fell comfortable on it.
On the long run, no matter how many languages I deal with - the unique one that is omnipresent is C. It saved my sorry ass countless times.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
Now .NET as a language isn't that bad, I actually like it..
.NET as a language isn't that bad because it's not a language. It's a frikkin framework.
Some apps are WYSIWYG. Some others are WYSIWTF.
Just because Bonamassa can make good music from a $30 guitar doesn't mean the guitar isn't shit. The fact that a good programmer can write a good programing a crappy language doesn't mean the language isn't bad. It just means the programmer is good enough to overcome the warts.
Dilbert RSS feed
How I envy the guy who will have to port your software to another OS or architecture /s
Dilbert RSS feed
If you still use Visual Basic 6 or remember it fondly, you should consider Real Studio. It has the philosophy of "simple things should be simple, complex things should be possible". We continually get VB6 developers that decide to move to Real Studio rather than switch to the current complex Microsoft ecosystem. Real Studio is as accessible as VB6, but is as object-oriented as VB.NET. Plus it creates cross-platform applications. Check it out: http://www.realsoftware.com/
Mister Platt is just a moron, and shouldn't be teaching if he doesn't know how to use a language..
One of the complaints is about ugly code, well you can write ugly code in ANY language, it's all up to the developer.. Another complaint by this moron is about 'On error resume next', well what's different to that as using:
Try
Call AFunction
Catch
End Try
It's exactly the same, and you don't have to use it... You can write about the same exception handling as you can in VB.NET..
And if you can't do it in 10 minutes, than maybe you should be patient and rethink or learn to use VB6 beyond the 'VB6 for dummies' level..
You can do very advanced stuff with VB6, YES you can also do multithreading if you want to, but debugging will be a bit harder and you shouldn't mind having the IDE crash (it's not like VS.NET IDE doesn't crash ever)..
If only they released the actual VB7 which was according to insiders only a few months away from a RC, and which would have had real OO like real Inheritance and function overloading.. Yes VB6 is getting old, but it has better long-term support from MS than a newby tech like Silverlight.. Ofcourse if you have to start a new (big) project you would be a moron to start it in VB6, but we still have a lot of legacy applications which still do the job they were designed for and no real need to upgrade it to any fancy UI/modern language.. Hell C# is the new VB...
So you feel that typing curly braces to let the compiler know what you want somehow makes for better code?
Perhaps it is just that you don't know any non C syntax languages. I do and after writing something like python then jumping into a c or c++ app it takes me days to get over having to type a bunch of cruft.
Got Code?
Quicktime won't cut it.
Yeah just don't try to free lots of memory in VB6!!!
Go ahead and try it...
or .net or java or any common application like firefox or chrome. Modern development doesn't free memory, it restarts/launches a new process. Garbage collection has been a joke since before we started measuring ram in gb instead of mb.
VB6 programmers are just lazy.
Java is simple in the least common denominator way. The language is very limited, and because it is so inexpressive and full of boilerplate it's the opposite of 'clean'. But those limitations allow low to medium skilled teams to produce code of a somewhat consistent quality, which is why it is so popular in enterprise.
Java has the same issues, also using an immutable string class, but they fixed it by hacking the compiler to recognise where you are doing string concatenation in a loop and make a StringBuilder out of it instead.
That was always how Java did string concatenation (except in the cases where the compiler detecting it was concatenating literals, where it did the obvious optimization) and it's the only sane way to do it if you're not using a mutable string model and yet still have string identity other than by value. (Languages that don't expose object identity can pull some clever tricks to hide the details.) If you're ever stuck trying to optimize some Java code, the first thing to look for is whether they are doing string concatenation in a loop; if they are, expose the StringBuilder and go from quadratic to (amortized) linear performance, a very nice win for a virtually-mechanical change.
Well, technically Java used a StringBuffer in 1.4 and before, which is just like a StringBuilder but thread-synchronized (and that was a mysterious decision, which is why it was changed).
"Little does he know, but there is no 'I' in 'Idiot'!"
They didn't lament the lack of operator overloading or polymorphism in Visual Basic 6, so they didn't say much
The summary is wrong: Visual Basic has polymorphism, it's the inheritance that is clunked. Google it, or enter here.
If timothy et al. don't know the language and environment, of course they won't understand the power of the little beast.
I don't agree with your death sentence, though. As years pass and I test language after language and environment after environment, I've come to respect the quick approach over the nice or correct one.
I rarely respond to comments. Also, don't ask for clarifications: a brain and Google are faster, believe me!
How I envy the guy who will have to port your software to another OS or architecture /s
Well, since the code is VB6 and asm, that guy has a good excuse to write it new instead of trying to port it. Which probably ends up producing better code. Provided he is a good programmer, of course.
The Tao of math: The numbers you can count are not the real numbers.
A good programmer, the languages are the tools.
I just deployed an update to one of the VB6 applications that I've been supporting for many years. That one, like most of the others, still works for what the customers want.
I would really like to convert those apps to .NET, or Java, or just about anything else. But it's an effort that, while it would help me, I can't really sell to the customers. It would be costly for them (hey - I can comp some time but can't do it all for free), as well as possibly introduce some new bugs (there's a lot of code in there), require time from them for testing and possible interface changes, etc. They just don't see enough advantages to want to do it.
So of course I have to keep some Windows XP VMs around so I can work on those apps. VB applications may run fine in Windows 7 (and presumably will on Windows 8, according to TFA), but the IDE does NOT. I don't remember all the issues I ran into (maybe it had something to do with the controls being used), but it simply doesn't work.
So, yea, it won't die, it will be around for a long time. But at least from my perspective, it has NOTHING to do with the developers not wanting to move on. It's a business decision. And business has almost no incentive to decide on change.
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
It's too bad that Delphi didn't win out. It was a much better language/environment that VB6.
Zoid.com
Exactly. VB6 is crap, but when the customer has an application they like, with lots of functionality, they are NOT going to pay to re-write it in something else just because some developer would prefer to use something different. If they need a minor change they are going to find somebody to spend a day or two making the changes in VB6, no matter how many developers keep telling them they need to spend a few weeks or months to update it to some other language.
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
2. Visual Studio 6 needs to run on Newer OS's Windows 7 64 bit... Windows 8?
It doesn't, actually. I can't make it work sufficiently to use. The compiled app works, but I have to maintain an XP system to do VB6 development.
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
Do date, there really isn't any IDE/Language that has targeted this audience of people who wanted to do RAD in this visual manner.
Wrong. There's Delphi. Say what you want about Pascal or OOP, but it is just as easy to program with as VB, it has an extensive third party component selection being actively developed (to do whatever you want, from serial communication to image processing and GUI components) and it is, somehow, still being sold and supported.
When .NET came around, its users were praising the ease of GUI development, something that Borland users already became accustomed to during the previous 10 years or more (with both Delphi and C++ Builder). With no dynamic libraries or virtual machines to depend on, every executable runs natively with the visual component library -- VCL -- that can be statically compiled in it.
Unfortunately tho, Borland changed its business focus and sold the whole thing (except the VCL) to CodeGear. The new VCL developed by CodeGear is meant to be compatible with the old Borland one, but it still has compatibility problems and, in general, is bigger. The last Borland-produced version of Delphi is the 2006 one and that's what I'm still using today for quick drag and drop GUI projects (when there's no need to spend more than 5 minutes drawing a GUI). And I know several people making tons of money selling and developing DB based programs with versions even older (Delphi was originally developed to provide an easy to use interface to DBs, that's why it is named after an "oracle").
They did developer VBs 7-10 and 11 is due out later this year. ...did you think that just because they adopted the .NET name, the version numbers just vanished?
VB versions are directly tied to Visual Studio versions these days. VB 7 was .NET 1.0/1.1, VB 8 was .NET 2.0/3.0, VB 9 was .NET 3.5, VB 10 was .NET 4.0, and VB 11 will be .NET 4.5.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
VB 6 is probably a better language for modest applications than Perl, TCL, or PHP. We're not making much forward progress here.
This is why when I develop applications with VB6, if I'm not satisfied with the speed, I typically use ASM as a back engine, and have the main interface and said engine communicate back and forth via commandlines and/or files. It might not be the most elegant solution, but it works in terms of stability and usability.
I can't wait for the Daily WTF post.
Web apps are more fun than VB6? At least in VB6 you could make the screen do almost anything you imagine with a few clicks. With web apps you are stuck with the page flow of HTML-related "standards", or else use JavaScript that probably breaks on some browser version or vendor you haven't tested, and looks jittery and forced.
The ability to make dialog boxes or help/wizard/lookup screens pop up anywhere for any reason is what made VB pleasurable: one's design GUI imagination can be satisfied without fuss and muss. The web is too restrictive.
I've been pushing for a desktop-like GUI standard over HTTP, tossing HTML and starting over in order to get a real GUI flow and screens. A GUI browser.
And coordinate-based positioning saves a hell of a lot of time and frustration. Auto-flow just doesn't control esthetics well: it's too dumb to know what "looks good" to humans. Auto-flow is an idea that looks good on paper, but is a time-sucker in practice.
VB-classic just plain hit on something that cannot be denied. (Some if it copied from HyperCard.)
Table-ized A.I.
It seems to me that there would be a good business opportunity for a company to make their own VB6 compiler and provide long-term support even after Microsoft drops it. Clearly the market doesn't want VB6 to go away, but one of the drawbacks of closed source is that one company can jerk people around like this.
...and they'll be right to do so.
Space game using normal deck of cards: http://BattleCards.org
I just don't get why so many find it hard to believe VB 6 has such long legs. it did ONE job and it did that job fucking brilliantly, which was to make an easy to use GUI front end to a DB, that's it, that's all. This is what MSFT fucked up with with .NET because frankly ALL of the VB 6 I've seen being used and being built really was only variants on that one function.
What MSFT refused to accept was was how important one small function can be to an SMB or SOHO. There is a HELL of a lot of times a small business can use a custom GUI to a DB, everything from contacts to records can be kept in a simple DB that just needs an easy to use front end so the user doesn't have to know anything about DBs, just fill out the forms.
Finally all those "real" programmers that gnash their teeth at even the mention of the word VB? GET OVER IT, you wouldn't expect them to call a 'real"engineer when all they need is something that can be banged together out of an Erector set would you? of course not and it just so happens there is a hell of a lot of business jobs that don't need some full blown SQL DB just to get the job done. Its just like how we've all seen "applications" built out of VBA and Access, it has its little niche and as long as one doesn't try to build something outside of its little niche? Then its a perfectly valid tool.
MSFT failed with .NET because they assumed if you were doing job A that you would want to learn to have the power to do jobs B-K, when in reality frankly there were tons of guys that frankly only needed to do job A so B-K were simply overkill and pointless. That is why VB 6 has such long legs, frankly there hasn't been any other language that filled the SMB small DB niche quite as well as VB 6.
ACs don't waste your time replying, your posts are never seen by me.
Yes, I know I got the acronym wrong. Twice.
You're comparing JBoss to .NET, interesting.
VS.NET has "Express" editions that are free to download and use (including for commercial use) and are quite powerful, so I'm not sure the "pay pay pay" argument holds up unless you mean development costs. I've used VS Express to develop COM components to bridge ESRI ArcGIS applications with other applications (eg in Java), and they are relatively powerful (certainly as much as VB6 was).
'enable very rapid development of limited programs by programmers of lesser experience.' '
Which then turn into unkillable custom full fledged enterprise monstrosities.
".NET is actually awesome,"
SUbjective, although I agree.
" especially when used with C#"
Subjective
". Java is too much bloat and slow and needs to die."
A ohhible sentence that is false
"But .NET is awesome and targets all PC, XBOX360 and Windows Phone 7"
Subjective
" And you can use the best IDE on the planet, Visual Studio, to develop."
False. It lacks several thing much older IDEs had.
So the only to things that aren't opinion are wrong.
The Kruger Dunning explains most post on
define crap.
The goal of a high level programming language is to crate applications that do what the customers want it to do. Not be clean, or small, or the best use of memory.
VB6 did that well, very well in fact.
Updating something that works to a 'new' language 'just cause' is a bad business decision. In fact, there is a lot of technical merit in not doing so.,
The Kruger Dunning explains most post on
And visa versa. You have added exactly nothing to the conversation. That's becasue there isn't really an argument against VB6 as a high level rapid development tool.
The Kruger Dunning explains most post on
Interesting, I wonder what things it's missing, I use it everyday, what glorious features is it missing that older IDE's had.
I believe the relatively new Lightswitch is an attempt to meet this exact need with the added benefit of creating a web deployable front-end.
I prefer VB.Net versus C# actually. I use both but C# has more complications without adding more functionality for most standard software development usage.
About Java: it may be false, but most products I have to use that are built in Java are pretty slow, and/or have an awful GUI. Apparently it is very difficult then to use it in such a way that you don't suffer performance issues.
But the main question I have is about the Visual Studio remark. While I know of one IDE that had realtime code compilation (pretty interesting tool to work with, it could take a context-free grammar and parse the language you described while you typed) and I would LOVE to see literate programming implemented in it, the usability of VS is, IMO, unequaled by any other currently available product. But please do point out alternatives, I'd be happy to try them.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
Now .NET as a language isn't that bad, I actually like it..
.NET as a language isn't that bad because it's not a language. It's a frikkin framework.
I think you're making a somewhat artificial distinction. I'd call it a part of the language, with VB-proper being the other part.
Microsoft made LightSwitch to meet this same business need of quick-and-dirty database applications - the tag line is "build custom business apps, coding optional".
A reasonable and fair comment.
This is also why Scala will never catch on. It's elegant and powerful, but requires a level of expertise, experience and interest that is way above the average of your typical enterprise app developer. This leads to code consistency issues, hiring problems, etc.
Nothing will take off, unless there's a reasonable chance of large, average-skilled teams building stuff consistently well with it.
I just don't get why so many find it hard to believe VB 6 has such long legs. it did ONE job and it did that job fucking brilliantly, which was to make an easy to use GUI front end to a DB, that's it, that's all. This is what MSFT fucked up with with .NET because frankly ALL of the VB 6 I've seen being used and being built really was only variants on that one function.
Pray tell, how is it any harder to make an easy to use GUI front end to a DB in C# or VB.NET, compared to VB6? WinForms is very similar to VB6 UI toolkit on basic level, with mostly the same principles and the same controls. ADO.NET is pretty similar to classic ADO, as well.
The VB6 compiler produced native code.
It produced horribly inefficient native code, though. Unless you were very careful with types, you could get stuff that run very slow. For example (like using Mid rather than Mid$ to extract a substring), it operated on COM variants, rather than raw strings, so it jumped through a bunch of hoops just to make sure all types are compatible and convert them if not.
Well, until today when MS has realised .NET performance and efficiency is crap and they need to go back to native code.
You do realize that .NET (yes, running on a VM with JIT) is actually still faster than VB6 ever was, right?
"Fast native code" really means C/C++. Something like VB is slow because it's high-level, not because it's not native.
Finally all those "real" programmers that gnash their teeth at even the mention of the word VB? GET OVER IT, you wouldn't expect them to call a 'real"engineer when all they need is something that can be banged together out of an Erector set would you? of course not and it just so happens there is a hell of a lot of business jobs that don't need some full blown SQL DB just to get the job done.
I'd be fine with that. Except that those little projects that just need to be banged together out of an erector set have a habit of growing, and becoming "business critical". They soon exceed the skills of those who banged them together, and they need to call a "real engineer" in to make it work again. Frequently, the existing software doesn't do exactly what it's meant to, or what the documentation (if there is any) says it does, and nobody wants to give any design criteria are "do what the old one does, but better".
In short, the reason "real programmers" hate it, is because sooner or later, it ends up being their problem.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
Q: a tool optimized for client server crud applications A: powerbuilder
In short, the reason "real programmers" hate it, is because sooner or later, it ends up being their problem.
In my business we call that a sales opportunity. When your job is to fix things, the more broke they are, the more money you can make.
-- I have a private email server in my basement.
In my business we call that a sales opportunity. When your job is to fix things, the more broke they are, the more money you can make.
If you were a contractor called in to fix it, I'd agree. If you're an in-house developer whose real job isn't to fix things, but to create new things, getting pulled off whatever job you were doing in the first place to fix someone else's mess is a PITA - and you don't make any more money.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
GDI calls to grab screenshots? 2003 AD integration? API calls to retrieve printers? SQL Server and MySQL support? They work fine. Even the ComponentOne COM controls, various user-defined controls (including one which uses a PictureBox to simulate an animated GIF), Crystal Reports runtime COM controls, integration with .NET DLLs, all of them work fine for me.
What have you found that doesn't work? I'm genuinely curious.
Just use Mono - "... an IDE primarily designed for C# and other .NET languages. MonoDevelop enables developers to quickly write desktop and ASP.NET Web applications on Linux, Windows and Mac OSX. MonoDevelop makes it easy for developers to port .NET applications created with Visual Studio to Linux and to maintain a single code base for all platforms."
http://www.monodevelop.com/
Laws and common sense still applies.
I think he meant Qt. And yes, Qt is a great framework for Windows. It integrates nicely with Windows and performs well. It also has the added bonus that if you ever need to port your app to Linux or something, you will only need to do a recompile and release. You would only need to rewrite the parts that use Windows-specific APIs or functionality but since Qt offers most everything it would hardly be necessary to build your app like that in the first place.
"It is a denial of justice not to stretch out a helping hand to the fallen; that is the common right of humanity."
I can attest to that, and I consider anything that involves VB as a crime against humanity for that reason.
There's a reason you hire programmers to write programs and when half-assed tools are sold to allow non-programmers to attempt to do the same thing, the result is never good.
You are in a maze of twisty little passages, all alike.
Because if I'm not mistaken you are talking about OO languages and Basic is a procedural language? At its core basic is frankly so simple and VB6 in particular is so simple for doing this one task that the thing practically builds itself. I've never bothered with .NET but i can tell you just from looking at the code that its language is a LOT more complex.
Sigh, I wish I still had my old VB6 code sitting on the hard drive instead of backed up on a DVD in the closet somewhere because i'd show that because of its very simple structure and built in autocomplete (intellisense I think its called? God its been years since i wrote in VB) that covered just about every variation one would want to use VB for you could bang out a pretty nice looking functional program in a few hours with a minimum of fuss. While i'm sure you could do something similar in .NET....once you learned all the new names and ways of doing things frankly VB was laid out so simple in its flow you could probably hack together a GUI with a dozen inputs for a DB without having to type more than 40 actual words, just letting the drop down intellisense fill in the blanks with the very logically named functions.
Hell I still use a VB program damned near every day in Win 7 X64, its a little app that scans a CD/DVD and puts the info into a DB and for that little job its bloody brilliant. its insanely fast, both at save/load and at search, it takes up almost no space, and you can just plop it onto a thumbstick and it works fine. ever since i got burnt with my old circa 2000 CD DB app being 16 bit and not running on X64 i always use two programs to back up the data (in case one is no longer functional in the future) and the other in this case is XML based and frankly it just isn't as good as the old VB one. Its slower in everything, especially slow in saving, takes up more space, and generally the layout just isn't as nice.
So VB has its place, as long as you know its limitations and don't go trying to force it into doing a job it wasn't really made for. Heck last I heard a little VB app I wrote in 04 for a local junkyard is still running 6 days a week, helping them keep track of where wrecks are in the large field and what parts have already been sold. for that simple task there frankly wasn't and isn't a point in hiring a 'real' programmer to write some large DB app, day after day it does its job very quickly on a little old 1GHz box that sits in the corner not connected to the network, and every day they back it up to a flash stick just in case the box ever fails. honestly if it ain't broke, why fix it?
BTW I apologize if I got any terminology wrong, i have a major skullthumper and I honestly can't be too sure on my nerd talk with a mule doing a tango on the back of my brain. Anyway i hope I got it right and explained it correctly and i'm sorry i don't have any of my old code to use as examples, peace.
ACs don't waste your time replying, your posts are never seen by me.
No, you're quite right. Most coders, even most of the extremely good and very productive ones, work the working week then go on to have some sort of a life outside work.
I'd go further and say *all* of the extremely good and productive coders work a standard working week and do something else outside their 40 hours.
There will be exceptions, as with any rule, but in almost all cases productivity goes down after 8 hours of solid coding. The marginal returns of coding past about 10 hours are negligible, and past about 12 hours the code quality drops to the point where it's actually counter-productive.
This is based on personal experience running a development team for years. Professional coders who take pride in their craftsmanship turn up to work, put in 8 solid hours of coding (well, OK, 6 hours of coding, an hour of meetings and an hour of admin/watercooler) and then go home. They meet their deadlines because they correctly estimate the effort required, and report deviations from the estimates early.
Working insane hours is acceptable for short bursts at crunch time. If it's consistently expected or needed then it's a management failure.
Absolutely agree. It's also totally counter-productive as it produces very low-quality code that takes longer to fix.
I once did a 36-hour shift to meet a deadline, and I spent most of that blearily trying to fix the mistakes I'd made an hour ago. I'd have done much better to go home after 12 hours and come back refreshed, but I guess that's a learning experience.
However, trying to explain this to a senior manager that doesn't look at (or understand) the results, and just sees your team doing 8 hours a day while every other team in the company does 12 hours a day can be difficult.
Business/App ideas are like arseholes: everyone's got one, they're mostly shit, but very rarely they contain a diamond
Now .NET as a language isn't that bad, I actually like it..
.NET as a language isn't that bad because it's not a language. It's a frikkin framework.
I think you're making a somewhat artificial distinction. I'd call it a part of the language, with VB-proper being the other part.
Yeah, while technically it's not a language, most of learning .NET coding is learning the various libraries in the framework. Whether you choose to manipulate those libraries in C# or VB (or any other language) is almost irrelevant.
Business/App ideas are like arseholes: everyone's got one, they're mostly shit, but very rarely they contain a diamond
VBA in Excel - the cause of more programmer misery than anything else, ever.
A very close second: the inclusion of MS Access in Office Professional.
Why did you do this to us, Bill? What did we ever do to you?
Business/App ideas are like arseholes: everyone's got one, they're mostly shit, but very rarely they contain a diamond
Actually, I'd say technically it is part of a language, because it provides the primitive in which you express your logic.
Yes, the real bullshit has been in larger businesses and corporate departments using VB. I agree with Access, Excel scripts, and VB being of real value to the small business world where no market exists to build software for a niche, but unfortunately these "tools" have been used in large businesses and the "solutions" have progressively grown into mission critical applications. Cracking open a VB app, one is likely to find something that is not scalable or adaptable, requiring the entire thing to be junked. With Java or .NET there is usually a hope of adaptability and scalability even if it is mangled.
I object to power without constructive purpose. --Spock
Summary: VB6 / VBA plus Access requires no support from the system administrator.
You have a sys admin who is solely interested in keeping his network up and running. You're in a department with little or no budget for development, but a need for database apps. System administrator has no interest in letting you touch his servers. And has no ability to develop apps. So you build a a VB / Access app, put the Access file on a shared network drive with other files, send the link to users, and voila, problem solved. An app which fills a real need.
This is probably not an uncommon situation in non-IT-oriented organizations.
To start with? paredit mode.
And to end with, for that matter -- when I'm writing LISP, anything without that one feature is completely and utterly unusable. And a REPL, and a good alternative to SLIME (for very tight integration between the IDE and that REPL)... though really, those features don't even make much sense when you aren't in a functional-programming world -- it's harder to swap stateful objects in a live instance than it is to hotload new versions of stateless functions (or just experiment with them interactively, leaving old versions bound to your namespaces until you're ready -- immutability makes all kinds of things feasible which would be unthinkable in an OO world where one has to think about state).
There are plenty of features which existed in system-image-centric language/runtime tools (a la Smalltalk) back in the day that don't exist any longer today, too -- look at the kind of integration Smalltalk tools used to have between the dev environment and the application instance under development. They went away for fairly good reasons IMHO -- but still: features, used to be commonplace, gone now.
Visual Studio may well be "the best IDE" for your own purposes -- but to be that without qualification, it has to be best for everyone. The world is full of people who aren't you.
Let me give you an example: I can tie into a running QA system remotely over a socket, interactively ask it "what would *this* call do if *this function* were replaced with *this other implementation*?", get a result (thus far without impacting behavior for any other users), tweak and retest that code without any compilation phases involved anywhere in the loop, and then decide to bind the new version to be exposed to other users once I've got it right. There's limited live patching support available in Visual Studio, yes, but it pales before what can be done with a good LISP.
Because if I'm not mistaken you are talking about OO languages and Basic is a procedural language? At its core basic is frankly so simple and VB6 in particular is so simple for doing this one task that the thing practically builds itself. I've never bothered with .NET but i can tell you just from looking at the code that its language is a LOT more complex.
VB6 was also object-oriented - it had classes and stuff. It didn't have certain features, like inheritance, so you had to do with interfaces + aggregation + delegation (and people did). You certainly couldn't avoid OO when writing even the most basic VB6 programs, though. Every form would be an object to begin with.
If you "never bothered with .NET", then I frankly don't see how you can make a judgement there. It lets you write complex code, for sure, much more complex than VB6 ever did, but it doesn't force you to write that kind of code. Especially not VB.NET, and especially not since 2005 or so where there was a concerted push to make things easier still, like adding "My" - with that change, e.g. forms could be operated in exact same way as in VB6, with automatically created instances.
frankly VB was laid out so simple in its flow you could probably hack together a GUI with a dozen inputs for a DB without having to type more than 40 actual words, just letting the drop down intellisense fill in the blanks with the very logically named functions.
See, again, you're judging something you haven't seen. In .NET with WinForms, you can literally hack together a GUI with inputs from DB without writing a single line of code - it's all wizards and drag and drop. Connect to database (wizard), then drag and drop that connection to a blank form and bam - there's your GUI, an editable grid of data with navigation, everything completely wired up.
As a side note, I do have a basis for comparison because I used VB6 a fair bit back in the day - it was what I started my career on back in 2000 (as in, not the first language I learned, but the first that earned me money). It was a decent thing for what it was, but I don't feel it to be superior to .NET in any way. The big problem with .NET early on was that attempt by Microsoft to get VB developers to learn the "real thing", meaning fully fledged OOP etc, even if the tech didn't really require knowing it to be used efficiently, at least not to any bigger extent than the original VB. I think that's where VB.NET reputation as a vastly more complicated language and framework comes from.
I can run Visual Basic 6 on my 64-bit Windows 7 install without any problems...
The only reason I have to do so is because we have a bunch of production tools at work written in VB6, half of which I appear to have become the other person who can maintain them when the person who wrote them is away (not because I could code VB6 - I'd never picked it up until I started my current job - but because I understand the thing it's producing data for).
I just wish he wouldn't use VB6 for something new he created in the last year or so. That and I wish he'd actually keep his code in revision control, and not scattered over his workstations' hard disks.
Yeah, I had a sig once; I got bored of it.
Yes it does work and has gold rating:
http://appdb.winehq.org/objectManager.php?sClass=version&iId=1325
Hate to point out the obvious, but .Net is not a language. It's platform that supports multiple languages. You know, there are an awful lot of bus drivers in .net world too.
This signature intentionally left blank.
I believe the relatively new Lightswitch is an attempt to meet this exact need with the added benefit of creating a web deployable front-end.
I've had a fairly in-depth look at LightSwitch. It's kind of pretty, but it has a certain opacity too. Try building a Make/Model/Year interface with it. It's possible, but I can guarantee you won't find it easy or elegant. In contrast, the third-party .NET code generator IronSpeed handles that pretty well, without driving you down the Silverlight runway. I've built a couple dozen IronSpeed apps, and it works pretty well at exposing a database to a web site.
Do not mock my vision of impractical footwear
It's "vice versa". And yes, there is. It's an extremely limited language, with no real support for any paradigm, most of the environment is not Unicode aware, it's tied to Desktop Windows and yet it cannot use .NET libraries, and finally most members of its community are brain-dead morons.
Dilbert RSS feed
VBA in Excel - the cause of more programmer misery than anything else, ever.
A very close second: the inclusion of MS Access in Office Professional...
(A) A disturbingly large amount of the world's wealth resides entirely on the common Excel spreadsheet. Carl Sagan-like numbers. Found that out working at the managed funds division of a major bank. Spreadsheets, with a rather enormous amount of VBA. Scared yet?
(B) There is a path for MS Access home-schooling. (1) Build business on Access; (2) Upsize Access DB with SQL Server back-end; (3) Systematically replace Access front-end with IronSpeed; (3) Become popular since their DB apps aren't crashing daily; (4) Become glum when the breathing room and feeling of success you've given your employer allows them to outsource your department to a hosted SAP house.
Been there, done that, ate the shirt.
Do not mock my vision of impractical footwear
VBA in Excel - the cause of more programmer misery than anything else, ever.
A very close second: the inclusion of MS Access in Office Professional...
(A) A disturbingly large amount of the world's wealth resides entirely on the common Excel spreadsheet. Carl Sagan-like numbers. Found that out working at the managed funds division of a major bank. Spreadsheets, with a rather enormous amount of VBA. Scared yet?
Yeah, I know, it's very very scary. I've worked in the finance industry and had the 'this is Fred, he's a casual worker we've had here this summer and he's put together a spreadsheet in his lunchtimes that is now business-critical for the entire Claims department. We need you to support it because Fred's going back to school now' conversation.
Surprisingly I managed to control my apoplectic rage during the discussions with Fred.
(B) There is a path for MS Access home-schooling. (1) Build business on Access; (2) Upsize Access DB with SQL Server back-end; (3) Systematically replace Access front-end with IronSpeed; (3) Become popular since their DB apps aren't crashing daily; (4) Become glum when the breathing room and feeling of success you've given your employer allows them to outsource your department to a hosted SAP house.
Step 1 is great, everyone's happy. Step 2 is always the problem in my experience (e.g. managers who copy the entire database onto a thumb drive to work from home on it). Step 4 is usually a blessed relief to be out of there ;)
Business/App ideas are like arseholes: everyone's got one, they're mostly shit, but very rarely they contain a diamond
You do realize that .NET (yes, running on a VM with JIT) is actually still faster than VB6 ever was, right?
Go ahead and use a post-VB6 version of .NET (VS2003/2005). Dead slow IDE, no editing of the code while running (WTF? if you are doing step-by-step debugging you _need_ to stop the program to edit a line?), and the result would often be a slow as hell application, that used a memory footprint of 3-5x the VB equivalent.
"Fast native code" really means C/C++. Something like VB is slow because it's high-level, not because it's not native.
You'd be surprised. I generally consider compilers like VB6 (and Clipper and some Cobol compilers) as "fake compilers" - they rely on an extensive API usually made in C/C++, and their work is to generate the glue code between the API functions. So, while your application logic usually translated to a series of call statements, the functions called run at native speed, and in complex algorithms, they run laps around early .NET implementations.
I can't make it work sufficiently to use. The compiled app works, but I have to maintain an XP system to do VB6 development.
Professional W7 versions have available a ready-to-use Windows XP, so it's not like MS doesn't provide a (half assed) solution.
WinForms is very similar to VB6 UI toolkit on basic level, with mostly the same principles and the same controls.
Except that the grid component is actually unusable for serious applications. You know, the thinggy 90% of the database-driven forms use. And the memory footprint of a "simple" database application reaches hundreds of MB easily. And the garbage collector sometimes forget to, you know, do some garbage collection.
VB6 was also object-oriented - it had classes and stuff. It didn't have certain features, like inheritance, so you had to do with interfaces + aggregation + delegation (and people did). You certainly couldn't avoid OO when writing even the most basic VB6 programs, though. Every form would be an object to begin with.
Since VB5, some OO features were available. But a form wasn't an object. There is a common misconception in the OO world regarding event-driven or message based programming - none of them is directly related to OOP. At its core (at least upto XP), Windows API is a procedural, event-driven environment. VB6 produced code vaguely similar to the classic C approach of creating a window, and registering a event handler callback. Zero OOP.
See, again, you're judging something you haven't seen. In .NET with WinForms, you can literally hack together a GUI with inputs from DB without writing a single line of code - it's all wizards and drag and drop. Connect to database (wizard), then drag and drop that connection to a blank form and bam - there's your GUI, an editable grid of data with navigation, everything completely wired up.
Except that feature isn't from .NET/WinForms, but from the IDE, so it's not directly related to the language. And as I said before, the .NET dbgrid sucks balls. Big balls. And the responsivity of the resulting application isn't nowhere near a VB one. And the memory footprint is massive.
As a side note, I do have a basis for comparison because I used VB6 a fair bit back in the day - it was what I started my career on back in 2000 (as in, not the first language I learned, but the first that earned me money). It was a decent thing for what it was, but I don't feel it to be superior to .NET in any way.
I've worked extensively with VB since VB3, and I agree that it's not generically superior to . NET - but VB.NET is not a VB6 replacement for the casual user, and VB6 (and FoxPro) left a void in the Microsoft ecosystem they haven't been able to fill since then.
Cracking open a VB app, one is likely to find something that is not scalable or adaptable, requiring the entire thing to be junked.
The same could be said for any legacy language. I know cases of banks that tried to replace their multi-decade old COBOL systems and failed miserably. The solution? Wrap around some JAVA or .NET middleware so they can continue to use it. .NET and some TDD, you are in for a surprise.
Critical applications are never really junked. You can't replace decades of ironing out the kinks and expected (mis)behaviour. Most of those critical applications grew with the business itself, and in some cases, specific chunks of code can span an entire generation of programmers. If you expect to replace it with JAVA and
I do some C# development, and often prefer to use SharpDevelop, despite its limitations (no LINQ wizards, no database browsing and whatnot). The code editor seems more familiar to me, and it is an order of magnitude faster than VS2010/2011.
Indeed it is half assed solution, and doesn't work at all on many computers, including my main laptop, because of the Intel chips with visualization disabled. I don't know why Intel did that with so many of their multi-core chips, but they did.
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
Yeah, I constantly forget the VM limitation in some processors (I ignored all non-VT core* cpus). It really is a WTF? moment for Intel customers.
There are many examples of this in the programming world. When AS3 was rolled out many coders thought it would change the web forever. It's an extremely viable, Java-like platform for web development. But it didn't fly. Most Flash developers stuck with the far more simplistic AS2 and ignored everything that came afterwards.
------ The best brain training is now totally free : )
I haven't seen anything to suggest that there's any correlation between programming language/environment and the hours that you are willing to work either. I think that's more about maturity as a person than anything else. I know now that I have and make enough money for the lifestyle I want, and I'm not interested in destroying that lifestyle to make more money. I think that most people who are smart, successful, and have good social skills feel the same way and do the same thing.
I have seen people work ridiculous hours at various jobs (and even done it myself at times) for some combination of:
1. Money. Either they have huge expenses for some reason (family, medical problems, debts) or they aren't skilled enough to make a good wage, so they close the gap between their wage and the money they need by working more hours. There's also quite a few job types where you can make lots more money than usual by being willing to work long hours and/or in poor conditions.
2. Unhappy home life. I've seen more than a few people work longer hours because they hated their wife/husband/parents/whatever and wanted to stay away from them. Probably some do it because they're lonely too.
3. Bullied/taken advantage of due to poor social skills. Excessive demands, threats to fire the person and maybe blacklist them in the industry if they don't comply, threats to fire them on the spot if caught looking for a new job, etc. Frequently combined with 1.
4. Passion. They're legitimately passionate enough about what they do to slog away at it endlessly. Can be great and tremendously productive, but rarely lasts more than a year or two at the most.
I don't reply to ACs
Go ahead and use a post-VB6 version of .NET (VS2003/2005).
I do that daily.
Dead slow IDE, no editing of the code while running
Edit and continue has been there for VB.NET since VS2005.
the result would often be a slow as hell application, that used a memory footprint of 3-5x the VB equivalent.
As I had already noted, VB.NET apps are uniformly faster than VB apps, because .NET JIT is better optimizing than VB6 compiler. If you really want it, I could do some benchmarking.
. I generally consider compilers like VB6 (and Clipper and some Cobol compilers) as "fake compilers" - they rely on an extensive API usually made in C/C++, and their work is to generate the glue code between the API functions. So, while your application logic usually translated to a series of call statements, the functions called run at native speed, and in complex algorithms, they run laps around early .NET implementations.
That's precisely the reason why they are slow, actually. A call statement itself is relatively slow compared to, say, just adding two numbers together directly. Yet a function call is precisely what VB will do in many circumstances. .NET JIT, on the other hand, compiles directly to native code, without an added layer of call indirection.
Except that the grid component is actually unusable for serious applications. You know, the thinggy 90% of the database-driven forms use.
I've used .NET grid for database-driven apps (I don't know your criteria of "serious", but it was a production app), and it was very fast.
By the way, which grid of the two (DataGrid and DataGridView) are you referring to? DataGrid was somewhat slow; DataGridView is blazing fast.
And the memory footprint of a "simple" database application reaches hundreds of MB easily
If you have hands growing out of your ass, perhaps. I've wrote quite a few .NET apps, and typical memory consumption figures were 20-50 Mb.
And the garbage collector sometimes forget to, you know, do some garbage collection.
.NET GC works just fine. I suspect that has more to do with people leaving around references to objects they no longer need (which very often happens with event handlers they forget to unregister). Otherwise, if you make bullshit-y claims like that, how about providing references?
In VB6, on the other hand, you could easily have a memory leak simply by creating a circular reference between objects. And there were no weak references to work around that.
Since VB5, some OO features were available. But a form wasn't an object. There is a common misconception in the OO world regarding event-driven or message based programming - none of them is directly related to OOP. At its core (at least upto XP), Windows API is a procedural, event-driven environment. VB6 produced code vaguely similar to the classic C approach of creating a window, and registering a event handler callback. Zero OOP.
VB6 form was a class and an object. It let one code procedurally by automatically creating an instance of the form when it was referenced, and letting use its members as if they were static (propagating them to that auto-created object). But you absolutely could create several instances of the same form with "New", and track them separately, same as any other objects - by storing references to them in variables, and then invoking methods on them. In fact, that's precisely how you wrote MDI apps in VB6.
VB.NET (from 2005 on) does the same exact thing.
Except that feature isn't from .NET/WinForms, but from the IDE, so it's not directly related to the language.
The feature in VB6 was an IDE feature, as well. And why would a developer care, anyway? The whole point of a RAD environment is that it's, you know, integrated.
. And as I said before, the .NET dbgrid sucks balls. Big balls. And the responsivity of the resulting application isn't nowhere near a VB one. And the memory footprint is massive.
So far everything you've said leads me to believe that you haven't actually seen .NET past 1.x, since you keep referring to outdated things and seem to be unaware of newer features and options. To that extent, your claims of responsiveness and memory use are rather dubious.
Edit and continue has been there for VB.NET since VS2005
Yeah, 7 years after the last release of VB6, and at the 3rd release of the VS suite with .NET support, so I guess it probably didn't affect many users _migrating_ from VB6. My mistake.
As I had already noted, VB.NET apps are uniformly faster than VB apps, because .NET JIT is better optimizing than VB6 compiler. If you really want it, I could do some benchmarking.
Maybe your code performs uniformly faster than VB apps, but it's not the general experience I have. Anything database-related range from about the same speed (with 2x or 3x the memory consumption) to noticeably slower. Probably some object-oriented code performs better when ported to .NET, but that's about it.
A call statement itself is relatively slow compared to, say, just adding two numbers together directly.
Usually is, but it is not an order of magnitude slower.
The .NET assembly is already the added layer of call indirection. And given the abstraction that datatypes suffer, I'd argue that whatever code is produced related to adding two integers will be much more extensive than the equivalent call generated by the VB compiler.
Yeah, 7 years after the last release of VB6, and at the 3rd release of the VS suite with .NET support, so I guess it probably didn't affect many users _migrating_ from VB6. My mistake.
It has also been 7 years ago. If you don't know where .NET was 7 years ago, what makes you think that you're qualified to judge on its verits vs VB6 today?
Maybe your code performs uniformly faster than VB apps, but it's not the general experience I have. Anything database-related range from about the same speed (with 2x or 3x the memory consumption) to noticeably slower
You do realize that database related stuff is bound by the efficiency of the DB framework and the backend database, not by codegen quality, right? In both VB and .NET, all codegen does is produce a bunch of method calls, for stuff like Recordset (in VB6) or DbDataReader (in VB.NET).
Furthermore, any comparison of perf in those circumstances would be meaningless unless you compare it on exact same data sources configured in exact same way.
Usually is, but it is not an order of magnitude slower.
Yes, it is. Count the cycles yourself - pushing arguments onto the stack (or, at best, loading them into registers), CALL itself, then the callee setting up his stack frame, and on return clearing it and RET. That's literally an order of magnitude slower than ADD.
The .NET assembly is already the added layer of call indirection.
If you mean IL, then it's not a layer of indirection at runtime - it is JIT-compiled to native code on the first method invocation, and that native code is what runs.
And given the abstraction that datatypes suffer, I'd argue that whatever code is produced related to adding two integers will be much more extensive than the equivalent call generated by the VB compiler.
There's no abstraction that datatypes suffer. Something like "Dim a, b, c As Integer ... a = b + c" will be translated to a single ADD instruction at the final point (after JIT-compilation).
By the way, which grid of the two (DataGrid and DataGridView) are you referring to?
I can't really remember which one I tested, we decided to replace it entirely with a DevExpress component, that we've been using since. At the time, even with virtual scrolling the grid was slow and had artifacts in maximized windows. I tested it with roughly 10k rows, 5-7 columns. A fast grid should take no more than 1-2 seconds to load and display the data on my desktop (quad-core 2.4Ghz).
If you have hands growing out of your ass, perhaps. I've wrote quite a few .NET apps, and typical memory consumption figures were 20-50 Mb.
I've just runned a simple app (less than 1Mb of source), opened a dialog with a list of 18 items pulled from a database, and it is eating 40Mb. The same application with just the main screen opened eats about 28Mb of memory, so I'd say 12Mb for a almost empty dataset, a grid and a form is a lot. I've seen datasets eating 200Mb of ram easily.
.NET GC works just fine. I suspect that has more to do with people leaving around references to objects they no longer need (which very often happens with event handlers they forget to unregister). Otherwise, if you make bullshit-y claims like that, how about providing references?
If you have to explicitly de-reference your vars, then you don't really need GC, do you? From what I've seen (and it is purely empirical), the GC seems to work with high and low watermarks for memory usage, and it only works "as expected" somewhere between a sweet spot, that varies according to the available RAM in the host. Given that true GC on a arbitrarily-sized heap allocator is computationally expensive, it does make sense it works that way, but for some applications - that require the load of a huge amount of data, some quick process on it, discard and repeat, usually leads to a fast depletion of the available RAM.
In VB6, on the other hand, you could easily have a memory leak simply by creating a circular reference between objects. And there were no weak references to work around that.
Yes, memory management in VB6 was a pain in the ass, but at a different order of magnitude. Today's computers have at least 8x the memory they had in 2000, the low-end cpus are at least 10x faster, and in many cases, the data size is about the same (a list of clients still is a list of clients, an article table still is an article table, etc). Modern db-driven applications usually aren't faster or leaner than they were 12 years ago, or - in many cases - better designed.
Most memory issues with VB6 could be easily fixed by using simple techniques, and using global datasets instead of arbitrarily opening and closing them inside forms and custom procedures and whatnot.
It has also been 7 years ago. If you don't know where .NET was 7 years ago, what makes you think that you're qualified to judge on its verits vs VB6 today?
Your original claim was that .NET is faster than VB6 ever was - it makes sense compare it in a time where .NET was touted as a VB6 replacement.
You do realize that database related stuff is bound by the efficiency of the DB framework and the backend database, not by codegen quality, right? In both VB and .NET, all codegen does is produce a bunch of method calls, for stuff like Recordset (in VB6) or DbDataReader (in VB.NET).
Assuming you actually believe what you write, then your assertion that "VB.NET apps are uniformly faster than VB apps" isn't true since - according to you - they produce essentialy the same code. .NET.Maybe it doesn't like me :)
But I mentioned "your code" because I didn't assume you were doing database-related stuff. I just mentioned that for database-related stuff you do get from about the same speed to a lot slower. That is the experience I have with the codebases I worked with. As an example, I've assisted on a migration of a midsize app (>700 forms) in 2003 from VB6 to VB.NET, and it took more than 6 months to become usable because of memory spikes and database-related issues. More recently, I've been working with C# (.NET 4.0) with both PostgreSQL (npgsql) and SQLite, and often memory usage goes trough the roof. I work with several languages/environments, sometimes working on the same data, and I usually only have this kind of problems with
This is the truth. VB is just an archaic, crippled language. It really isn't that bad as long as you don't mind re-writing every library that comes with real programming languages. VBA, however, is the worst development platform I've ever used. Nothing else even comes close, although I can say I've never done Lotus Notes development. Microsoft even acknowledges this. They do NOT support VBA.
Any manager that allows VBA applications to be used should be summarily executed. Office itself is a nightmare, but it is possible to do some useful things with Excel, as long as you don't try to program it. Word on the other hand is so bad, it's not only unusable, it's literally ruined the concept of word processing. Everyone tries to copy it since Microsoft has a monopoly with Office, but it's a horrible, disorganized, unpredictable mess that violates practically every usability standard and convention as well as common sense itself.
It's the second worst piece of software I've ever used that wasn't designed for the "enterprise". The worst is Access. Enterprise software" is of course a euphemism for software that looks like it was designed in the 1970s, by angry, confused people who have never seen or used computers before, and runs almost as well as it looks. I have yet to use an "enterprise" application that wasn't like being kicked in the nuts with a jackhammer.
You are in a maze of twisty little passages, all alike.
I wouldn't touch .NET with a ten-foot pole, so you're not talking about me. I did serious Windows development in the pre-.NET days, and it was actually a pretty good time and platform to work in. Visual Studio 6 was a decent IDE even if the editor was archaic. Of course, MFC was a half-hearted and half-assed first draft of a library that was obviously written by a high school intern on a Friday afternoon in between foozball games, but I was able to turn it into something pretty useful because it was C++ and I could derive useful stuff from its bare-bones, do-nothing classes. I was very productive with it and wrote some really cool apps.
None of my employers or clients ever wanted to move past VS6 when the .NET stuff started coming out, which was fine by me, and the more I hear about .NET these days the less I want to use it.
Of course, I've been doing Linux work for the last 7 years, so I've lost what little interest I had in Windows development.
You are in a maze of twisty little passages, all alike.
I used to have a programmer buddy who'd say "If I ever go postal and you see me hauled off in cuffs you'll know it was Excel or Access that drove me to do it!"
But I'll tell you like I told him "Whose fault is it REALLY? Whose to blame?" and the answer is the PHBs and the BOFH IT guys that won't let them have even a free IDE like Netbeans or Eclipse but what is installed on damned near every PC? Office Pro.
So in those cases you can't really blame Bill for all these guys using VB or Excel or Access to make things they were never designed to do, but the suits that won't give them the tools to use anything better. It would be like telling someone to build a house but only giving them a tire jack and a rusty saw to do it with, can you REALLY blame them if the house turns out to be a lean to with a leaky roof?
ACs don't waste your time replying, your posts are never seen by me.
I've just runned a simple app (less than 1Mb of source), opened a dialog with a list of 18 items pulled from a database, and it is eating 40Mb. The same application with just the main screen opened eats about 28Mb of memory, so I'd say 12Mb for a almost empty dataset, a grid and a form is a lot.
Most of it is for .NET itself - VM, JIT etc. If you, say, add a dozen more grids and forms, it won't take noticeably more.
I've seen datasets eating 200Mb of ram easily.
Um. A dataset is an in-memory, client-side cache of data from the database. If you load 200Mb of data into it, that's how much it's going to eat.
If you have to explicitly de-reference your vars, then you don't really need GC, do you?
No, you do. The point of GC is to deallocate objects to which there are no reachable references.
There are some stupid things people do, like nulling out locals before returning from a method, or nulling out fields in Finalize. Those, of course, don't have any effect on the GC - it doesn't care about the values of variables which are no longer there. But for those that are, it assumes that if they can be traced starting from GC roots (i.e. globals/statics or locals), they're there for a reason.
The usual reason for a GC "leak" in .NET is when someone registers a method on an object as an event handler for some one-off event, and forgets to unregister it. So long as the component that was providing the event is not gone itself, it will keep a reference to the event handler, and therefore to the object - and everything else it references.
rom what I've seen (and it is purely empirical), the GC seems to work with high and low watermarks for memory usage, and it only works "as expected" somewhere between a sweet spot, that varies according to the available RAM in the host. Given that true GC on a arbitrarily-sized heap allocator is computationally expensive, it does make sense it works that way, but for some applications - that require the load of a huge amount of data, some quick process on it, discard and repeat, usually leads to a fast depletion of the available RAM.
That's not how it works. It obviously doesn't kick in on any allocation, but it does do collection periodically, and it also keeps an eye on memory pressure, and in a scenario like you describe - allocate/process/dealloc - it will actually kick in pretty often (which will negatively affect perf, however).
But Java and .NET really doesn't fit the SMB niche because as one put it above you "Its a OOP minefield" that has a pretty decent learning curve, whereas frankly a weekend with VB 6 could have virtually anyone cook up a basic GUI front to a DB which is a BIG need for small businesses.
Hell I'm not a programmer but a VB6 program I wrote last i heard is still being run at the local junkyard. All it does is they input where on the lot they put a new car, we divided the lot into a grid with 22 rows lengthwise (since while they can grow sideways the highway blocks any further growth lengthwise) and when i had finished it I believe it went to J across but of course they can keep adding letters or even double letters if they expand that far so that all they do is either type in or pull down a make and pick the model from the list and it would give them a grid location, like say G14,B09,C12 if they had multiples of the same car.
It really was a nice little app for that one little niche that would have probably cost them far too much to have written by a 'real" programmer. They didn't even have to pay me in cash, I swapped it for a nice set of rims for my King Cab I had at the time LOL!
ACs don't waste your time replying, your posts are never seen by me.
Your original claim was that .NET is faster than VB6 ever was - it makes sense compare it in a time where .NET was touted as a VB6 replacement.
I don't see why. That battle is already over, one way or another. When I compare VB6 and .NET, naturally I'll be doing that based on their current performance, since that's what is relevant today.
Assuming you actually believe what you write, then your assertion that "VB.NET apps are uniformly faster than VB apps" isn't true since - according to you - they produce essentialy the same code.
When it comes to stuff like databases or UI, yes, absolutely, they do - because 99% of that code is just calling into the framework.
On the other hand, for things like, say, arithmetic computations, or sorting, any other CPU-bound algorithm, VB.NET will run circles around VB.
But I mentioned "your code" because I didn't assume you were doing database-related stuff. I just mentioned that for database-related stuff you do get from about the same speed to a lot slower. That is the experience I have with the codebases I worked with. As an example, I've assisted on a migration of a midsize app (>700 forms) in 2003 from VB6 to VB.NET, and it took more than 6 months to become usable because of memory spikes and database-related issues. More recently, I've been working with C# (.NET 4.0) with both PostgreSQL (npgsql) and SQLite, and often memory usage goes trough the roof. I work with several languages/environments, sometimes working on the same data, and I usually only have this kind of problems with .NET.Maybe it doesn't like me :)
I've been working in C# for 10 years now - pretty much since the release of 1.0 - and I never had troubles like that, and that was also for database-centric apps. I don't know, perhaps this has something to do with database backends you're using? I've mainly dealt with MSSQL, with a bit of Oracle and .mdb files (via OLE DB) thrown into the mix. I've never used PGSQL or SQLite from .NET, so I don't know the quality of those ADO.NET providers.
We have a dedicated Access programmer. Nice guy, but I shudder when I think about the mess...
Cheap storage VM.
or .net or java or any common application like firefox or chrome. Modern development doesn't free memory, it restarts/launches a new process. Garbage collection has been a joke since before we started measuring ram in gb instead of mb
I'm going to go with ignorance over malice on this one. Even a modest (processing or I/O limited, as opposed to blocking) application will churn many megabytes of non-stack-alocateable memory per second for all but nearly trivial tasks. Much much more very often (hundreds of megabytes a second in bursts or some specific tasks). You'll run out of real memory before you can do most things.
Now that could be handled by explicit memory management, but that adds a lot of work and a whole new class of bugs. Lots of languages would have to the stripped to their core to replace the GC mechanism with explicit memory management. Ruining milenia of man years woth of code in the process. Also there are some incredible data structures built on top of CAS instructions which don't require locks to be thread safe, relying instead on so called atomic instructions for correctness. This can unchoke some of the toughest bottlenecks to crack in a large application, but it is nearly impossible to do correctly with explicit memory management especially once complex (read: useful) data structures start piling on top of each other. The scope of the problem spirals out of control.
Last, and best of all, GC can (CAN but isn't always) be cheaper than explicit memory management. It goes like this:
Allocate a few new objects on the heap, making a mmap call for each. Mmap does some really intreseting things which I'll skip here and returns you a word aligned chunk of memory at least as large as the one you requested and ALSO does a bit of bookeeping so that later (or concurrent!) calls to mmap and free can, well, manage memory (in concert with the OS. More incredibly intreseting details and subtle elegant solutuions here. Really. Read up on virtual memory and browse the GNU C-lib's documentation on memory management)
You make use of these objects and free them (becaue otherwise you run out of memory, see above). Free costs cycles to call. It has to work with mmap and other free calls to do bookeeping and make sure your program's heap is more than just a byte array free-for-all.
In a GC system the allocation can be deadly simple, far simpler than malloc. Check out all the various GC schemes (G1GC in Hotspot 7 is a good one and I've found it easy to understand on a conceptual level) They know where the free bytes are and allocate against them without much regard for saving every byte of space and calling malloc very rarely, jsut stuffing things where they fit. They can do this because the generational assumption holds. Most objects die young. When the GC cycle comes around a block of memory, regardless of the number of objects it holds, can be freed with perhaps a single byte written into memory. The even better part is that most "precise" GC systems run in time relative to the live objects, not the dead ones. This means that even if free ran in a single instruction and didn't blow out a single line of L2 cache the GC system can take less time. It often takes more effort to trace the heap from the roots, but not always. Probalistinc instead of hard guarantees and incremental instead of continious, but it gets you a lot of freedom and a TON of opportunities to exploit parallelism (manual memory management in non GC languages on objects touched by multiple threads can be tantamount to writing your own GC. incredibly slow or worst: wrong (as in incorrect, not morally))
So GC. Yeah. Heck of a thing. Really, I'd say, makes computing and programing as we know it possible. Heck, even GCC uses a GC.
md5sum
d41d8cd98f00b204e9800998ecf8427e
I just don't get this. Everyone's talking about VB6 as if it's never used for anything serious. All my VB experience (going back to VB5, let alone 6) is full blown Enterprise distributed apps using VB as the front end and middle tiers via DCOM, with as much object orientation as VB can muster and with SQL Server as the back end. We've got systems supporting hundreds of users, hundreds of tables and millions of records and sub 2 second responses for everything. The servers are really low spec too - typically NT4/512Mb RAM and RAID 5 arrays.
I'm sure there are some people out there cranking out simple apps but that doesn't mean VB can't do a fine job of being used to build very reliable, high performance Enterprise class systems.
I want a list of atrocities done in your name - Recoil
Wrong. VB5 introduced native code compilation and VB6 continued to do so. The default option for a new project was P-Code, but one click in the project's properties changed that. But a lot of programmers did not understand when to pick P-Code over native compile. The later would only make a noticable difference if your code did heavy computation (aka "number crunching"). People expecting performance gains from native code for their DB queries failed to realize their their borked SQL statement or underpowered DB server can't be solved by a VB native code executable.
Which shows again: it's not the paintbrush - it's the artist! I can't tell you ho many VB sample code I've seen over the years, both on MDSN and from commercial components, where you had something like this in it ...
... without an accompanying ...
... and expecting a and b to be of Long data type, too. Or using Variant string functions (Mid, Left, Right) instead of String string functions (Mid$, Left$, Right$) and then lament on how "slow and inefficent" VB is.
This shows that a lot of people who were complaining about VB didn't know how to use it properly.
Good sig!!
Social Credit would solve everything...
Did you seriously just say VisualStudio sucks because it doesn't auto insert brackets? I'm pretty sure thats what you just said once the bullshit was translated out of it. I'm fairly certain you're rather inept at using computers.
Also did you seriously imply that all the VisualStudio editors function the same? I'd take a guess that your problem is whatever LISP addin you used for VisualStudio sucked.
It may not be the best for anyone, but your reasoning for it sucking is pretty ignorant.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
In contrast, the third-party .NET code generator
You're doing it wrong.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
A career in tech is bad enough as it is....
You sir, are a spoiled brat. Seriously, you have no idea what 'bad' is if you think your desktop is horrible.
no opportunity for upward mobility without shifting to a completely different role that requires a completely different set of skills and training....a tight ceiling on the salary....spending most of your day typing on a computer rather than socializing...and so on. Working long hours without at least collecting overtime pay for them just adds injury to insult.
Ignoring the socializing part since I think you fail to understand that work is about you are performing a service for someone else, not clubbing ...
Everything else you listed there is true for virtually every job on the planet.
My god, they fucking expect you TO WORK for a salary?!?! Those sons of bitches! If you want hourly pay, ask for it, I'm 100% certain you're employer would love to give it to you. Go ahead, that'll be a nice way for you to get a clue and what you deserve.
Actually, I'd wager to bet you don't even work summer jobs between school sessions, do you?
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
No, I didn't say Visual Studio sucks. Go read my post again -- this time, paying attention only to the things I actually said and not whatever hyperbole you happen to feel like adding.
Keep in mind, I was responding to someone whose claim wasn't "doesn't suck"; the claim was general-purpose superiority. (Moreover -- I don't doubt that someone could write a LISP mode with SLIME-equivalent support, but until such a thing exists, that still doesn't make VS the superior environment for folks working in LISP).