I hear Tales of woe. Here's my tale of no woe. AMD 900. 384 meg ram. Note thats a 900 not a 2900. W2k - 2 monitors On this box I run : Cybertrader pro, many windows and charts 2 IB accounts 3 or 4 Excel instances running various VBA macros using DDE feeds These macros monitor ES, NQ, Multiple diff stocks, use web queries running in a loop, constant polling on DIFFERENT stock symbols. 5 or 6 IE browsers. Chat Anything else, MP3, etc, whatever amuses NO PROBLEM WITH SPEED OR PERFORMANCE REAL TIME. Guys, you are spreading old wives tales. I can't speak for supporting 1000 users on a network or anything I haven't had to deal with, but I've yet to see a problem with speed. As far as what qualifies as a good programmer, well, last time I looked, a good programmer gets it done, anyone else gets the door.
stock7^3: It is believable to me that you could do all those things with VB, and that you are happy with VB. But it is illogical to infer that since VB is adequate to your needs it will be for everyone's. Actually, I acknowledge that for some of my needs, VB would be enough, performance-wise, but that's not the whole story, see below. My most critical needs are very cpu intensive so code efficiency is of paramount importance and I wouldn't consider anything but C++ after having tried VB, Pascal and Java at some point or another. I am not trying to start a religious war, just trying to give sound, practical advice to any newbie that could be lurking here. Not to mention multi-threading capabilities, portability to UNIX and Linux, and Object-Oriented design. C++ not only gets the work done, it also makes it easier to do software maintenance. Your apps grow with your needs without becoming overbloated monsters. When I hire a C++ programmer I think "investment": that code will be useful to me for a long time. VB programmers have been nothing but "expenses" in my experience.
Everyone has different experiences and perceptions. You believe you're better off hiring C++ programmers - which hopefully has worked well for you. On the other hand, I've wasted a ton of money on C++ programmers - especially those coming out of Unix environments and trying to write complex Windows software. Ideas about capabilities and appropriateness are also often masked by perception. Multi-threading - I do it without problem in VB. Portability to Unix/Linux - only a factor if you need the software to run on both Windows and one or more flavors of Unix, but since most don't it's usually not a key/deciding issue. Object Oriented - not really a problem - in VB6 the only real limitation on OO design is that VB6 uses interface inheritance rather than also implementation inheritance and overloading. Not ideal, but it works and even after a lot of large, N-tier, OO-based systems, it hasn't proved a significant issue. Although VB.net does add implementation inheritence and overloading. Modulus - "lousy" was probably a poor term. Perhaps "inappropriate" or "lacking specific experience" would have been better. There are loads of long time programmers (with and without Masters) who code just fine and do top notch jobs in the areas they know, but can be myopic about key design issues or lack the relavent experience to make certain critical design decisions when working on something outside their area of expertise. Example - in the T&S window example, a programmer could easily code it very nicely and cleanly but if they made the mistake of using a grid control or listbox as part of the implementation because it was convenient and because it works fine for non-RT applications, then that single design mistake could easily mean the difference between an implementation that uses single digit CPU and 100% CPU. Similarly, for a vector graphics app, using the rudimentary native VB line drawing instructions or the basic MS Chart control will work fine for a lot of applications but if you're doing high-demand vector graphics the difference between doing that and using the Windows GDI functions (either directly or via a simple set of graphic objects) is a couple orders of magnitude. But if you don't know that, then you could easily write a very nice and clean program that didn't work well. Bottomline - language choice remains more religious than pragmatic for individual programmers (ask a Java zealot and you'll see what I mean). In that case, you should use what you're comfortable with but if you're venturing into RT applications for the first time - try to get design help from someone experienced or expect to do a lot of reworking. Because the design is usually more important than the coding or the language. But for businesses, the issue is about the specifics of what you're trying to do (e.g., support both Windows and Unix), what can be used most cost effectively and time efficiently, and most importantly whether you have appropriate experience designing/implementing what you're trying to do regardless of the language you're writing it in. Ultimately - there's no such thing as the "best" language to use overall. Except for BLISS of course - that WAS the best language - LOL
For me C++ is a pragmatic choice, VBasic creates more problems than it solves, C++ is a pain to program, requires patience, but works like a dream. Multi-threading, OOP in VBasic??? Please... have you ever tried TRUE multi-threading, TRUE OOP in C++??? There's no comparison, end of discussion. I have to agree with this. Finding good C++ programmers is a pain. I have to micro-manage a lot and I end up writing most of the stuff anyway. UNIX programmers actually tend to be better than windows, better programming habits. There is nothing complex about Windows just microsoft BS to make it nonportable. If you think windows MFC is complex, you haven't used MOTIF.
"Similarly, for a vector graphics app, using the rudimentary native VB line drawing instructions or the basic MS Chart control will work fine for a lot of applications" ... Just a technicality, but you can't do a stock chart in VB with the MS Chart control. The stock chart that works in Excel does not work in the Microsoft Chart control - only line charts, etc.. You would have to insert an OLE control container. And then it gets real tricky. If I'm wrong please post the code on here for us - thanks.