with it myself. By the time I had been exposed to it enough in use to want to learn it to "fix" the poorly written software I was using, I had already learned C++ and Java and had determined VB probably wasn't worth my effort.
It could very well be that VB is very good for some things. And it could simply be that the software I'm dealing with was just poorly designed and VB has nothing to do with it. (that is becoming more apparent as I find more problems) Perhaps VB lends itself to such practices, but more likely any language can be used to program junk if the coder has poor discipline.
The particular software I'm dealing with is maybe even out of scope of VB's capabilities or suitability. (It's a retail Point of Sale System with accounting functions) My biggest gripe I think with the design is that "features" were added, like a custom print dialog, that simply aren't necessary. The standard dialog does the job. (and is used in other parts of the program) This lack of consistency and having this special code in some places which doesn't always work right, is starting to be quite a pain.
It's really a bummer because I can't run this software under Wine because of these special VB features. I've tried to install VB in Wine first, to no avail. So I'm stuck with a VM for the time being.
The larger problem also is that the entire system is not database driven. Which to me, for a POS system is just mind boggling. The history of this app is that it was originally written for DOS (which I'd LOVE to have copy of to see if it was any more sane) and then ported to Windows back in the late 80s early 90s. My guess is the programmers didn't yet know all the special classes and calls for GUI environments in those days, and so when VB came out, they jumped on it and I think have been just hodge-podging it ever since. The software needs a total re-write from the ground up.
That is in fact, my current project. I'm not even bothering to re-write their implementation though, I'm just going to create what our company needs from scratch, with their example to keep me in check with definitely how not to do something.
I myself am no ninja of code. I'm still wet behind the ears but try to advance as best I can. I still haven't finished my degree and plan to go back this fall if funds permit.
I got my start at about 10 on a RadioShack TRS-80 CoCoII with 16K of RAM. I didn't even have a cassette recorder to save my work until I was 12 or so. (yes, that was 2 years of spending hours typing in programs and then having to lose them when I turned off the power - and no, I didn't have a printer to save them to hardcopy either - yet)
I ran a lemonade stand those two summers and saved up for a CoCoIII, a cassette recorder, a dot-matrix printer, and later a 5.25" Floppy drive. I never made it to the harddrive stage, so I was still pretty limited but I did dabble with an OS called OS-9 by Microware that was multi-tasking and even had a GUI. (before Windows) I continued Basic programming into early highschool and did all my school work on that machine.
I never did get the hang of assembly, though I always wanted to and will get the chance as it is a required course in a semester or two.
For some reason, I moved on to Windows machines and never did get back to coding until about 6 years ago when I started teaching myself how to do web design. That's when I decided to go back to school and learn real programming.
If you are interested in C++ it really isn't that bad or difficult if you have the right books to guide you. My text was a bit dry, but I found a much better one at the bookstore: Sams Teach Yourself C++ in One Hour a Day. (ISBN-13: 978-0-672-32941-8, $45 US)
It's a 29 day course with one hour of study each. (roughly) When you are finished, you should have experienced two semesters of C++ programming. (at my university that is)