VBA vs. C++

I do a lot of trading software development like risk engines, VaR, Monte Carlo simulators, portfolio management, trade selectors, A.I., etc. I've contracted for Value Line, Inc., Fox futures, Futures@net (built the risk engine), APS Electric energy trading department and others. So this is what I do for a living. I've used C++, Java, .Net, Pascal, x86, old C, and Visual Basic from VB DOS all the way through 6.0 and .Net., PowerBASIC with inline assembly, and other stuff. I've used it all extensively. Now I use VC++, VB6, ASP, SQL and Java everyday, and C++, Perl and Java under UNIX often.

This is my two cents about this subject... in regards to trading software development and these languages with required runtimes. Each language (except for a couple) have their own place and special purpose. Runtimes are required everywhere.

Everyone's favorite: VB4 through VB6.

Visual BASIC... Beginner's All-purpose Symbolic Instruction Code.
VB and VBA are very popular languages, and the reason everyone loves the language is because it is easy to use and Microsoft pushed it on us like crack cocaine. VB makes excellent front-end GUIs and database clients, but stinks with drawing and algorithms. I use VB6 for a front-end every day, but I don't care if you compile with P code and optimizations or not... VB IS SLOW when it comes to intense processing and graphics. You might not notice if you have a fast computer. Even though VB allows you to do sloppy coding with variants for everything and other nonsense, its an easy language to work with and it allows you to get what you want done, in a hurry. Usually, being in a hurry isn't the best thing when it comes to programming.

Every once in awhile you'll find existing VB or VBA code that needs to be speeded up but there's just too much to port.
Only in this rare occasion I'll whip out PowerBASIC. PowerBASIC uses VB syntax to the point that you can cut and paste your VB code into it, and almost compile. With PowerBASIC your VB application is speeded up over 2,300% right from the start. Then you can optimize with CPU registers and inline x86 Assembly. PowerBASIC can be as fast as C. OOP is almost out of the question.

C++ is no doubt a tough language to use. Its a lot more difficult to use than Java because you have to worry about memory management. But boy is C++ FAST at drawing and processing. If you know how to use it, it comes in handy every time.
75% of my coding is done in C++ to begin with, because I'm comfortable using it. Like the other guy said, its not a language that you want to learn just to write one program with.

Java is next on the list. Its slower than C++, faster than VB but it doesn't matter... Java is all about developing object oriented cross-platform applications, to run on a network usually. Sure you could use it to build a desktop application but its not well suited for this purpose. Its better for writing cross platform network applications and small hand held programs. For instance, I'm using J2ME (Micro Edition) right now to emulate a Nokia cell phone on my Windows 2000 development machine. With J2ME you can develop software that runs on Nokia 3G phones, PDAs, other small devices, etc. Its a great language and easy to use, also well supported.

.Net (C#, VB.Net, etc.):
It is highly unlikely that anyone using VB6 will enjoy using VB.Net. In fact, it may make a VB'er take to the bottle.
That is, VB.Net is actually a Java-influenced VM framework with BASIC syntax. It is very object oriented and in fact shares some of the architecture with Java. C# is about as useless as tits on a bore hog. And this goes with all .Net languages. The syntax is familiar, but the VM stems from the 1997 Microsoft vs. Sun Microsystems's lawsuit in regards to J++ and Sun's Java language. If there ever was a language that needed a CD FULL of runtimes, Virtual Machines, etc, its .Net. If you need cross platform programming, go with the real deal: Sun Java.

In conclusion:
1) VB is great for a GUI front-end and light applications
2) C++ is better for graphics and heavy duty processing
3) Java is nice for networks and small devices


Richard
 
ModulusFE, I'm curious. Could you give an example of a real application that was attempted, in lets say Excel VBA, that was too slow?

Hard for me to imagine anything so intense, than it would be unusable vs a C program. I'm assuming of course, that the VB or VBA app is being written by someone that has a clue, or knows where to find one.
 
I had a simple, little project a while ago: I wanted a scrolling time-sales window color-coding each line according to preset criteria: example: trade at best bid, at best ask, accumulated volume at last price to see visually when price is meeting support/resistance etc etc.
I wanted to be able to open several time&sales window at the same time, so for example you could setup two big t&s windows in a single monitor in a multiple monitor setup.
I hired someone to do this, and he did it in VBasic. It worked, but the processor load was horrible. At high volume times said program made the computer choke: 100% processor load.

So if VBasic is not usable to program a simple t&s windows application... you get the idea.

This story has a happy ending though. Using C++ the same task (scrolling full-screen t&s windows) never takes more than 6% processor load in the same machine that used to choke with the VB program, so you still have enough resources to do other work... the windows look nicer and the scrolling is smooth, flicker-free... and the big plus: almost the same C++ code works in UNIX/solaris boxes...
And thanks to OOP it was almost no work to incorporate the t&s windows into my proprietary charting app.

I don't want to hear anything about VB since. Also, I don't see any advantage to the .NET framework, it's just another marketing ploy to sabotage SUN's Java promise: cross-platform software compatibility.
 
VB/VBA is fine for everyday light development. But don't use it for building a COM object that run's a commercial web site's risk engine, especially if it supports over 1000 users at the same time. I inherited that project and had to port it to C++. The original code wasn't sloppy, it was just slow. Originally it was only supposed to be prototyped in VB and later ported to C++ (as is often the case). But so much work went into it that they decided to put it into production. It couldn't keep up with the requests and slowed the servers down to a crawl. There where some very intense algorithms in there. The C++ port improved the performance by 1000% or more. But on the other hand, I find a lot of VB COM objects that run on commercial web sites without causing a bottleneck. It depends on what the application is required to do. Another thing you wouldn't want to do in VB is write a Monte Carlo simulator for risk... or some batch program that runs all night. Those missing microseconds turn into hours.
 
Quote from ModulusFE:
Another thing you wouldn't want to do in VB is write a Monte Carlo simulator for risk... or some batch program that runs all night. Those missing microseconds turn into hours.
More...
It makes sense to me.
 
Quote from buzzy2:

I wanted to be able to open several time&sales window at the same time, so for example you could setup two big t&s windows in a single monitor in a multiple monitor setup.
I hired someone to do this, and he did it in VBasic. It worked, but the processor load was horrible. At high volume times said program made the computer choke: 100% processor load.
More...

buzzy - the problem probably wasn't the use of VB, it was a lousy programmer. He probably did something stupid like trying to use a grid or listbox control as a quick but inappropriate way of managing the realtime scrolling window. That would easily blow the top off your CPU utilization.

I did a similar quick program a year or so ago for a friend who wanted a T&S display with some bells and whistles he couldn't get elsewhere. I did it in VB using a component architecture and handling the display efficiently and the CPU utilization sat at single digits even with a dozen windows open.

The simplistic myth that VB (not VBA) is only good for light duty applications is the result of looking at the wrong driving factor. Almost always the issue isn't the language - it's the programmer.

The simplicity of VB is sometimes a negative because pretty much any schmuck can code some things in VB and call themselves a VB programmer, but it doesn't mean they really know what their doing. They might not use sloppy code, but a sloppy or inappropriate design is even worse.

Half-assed design results in half-assed performance - regardless of language.

There are a lot of lousy C++ programmers out there who have no business working on anything of consequence, but since there are so many more VB programmers there will naturally be a lot more lousy VB programmers. :)
 
Quote from ArchAngel:

I did a similar quick program a year or so ago for a friend who wanted a T&S display with some bells and whistles he couldn't get elsewhere. I did it in VB using a component architecture and handling the display efficiently and the CPU utilization sat at single digits even with a dozen windows open.
More...
the VB program I have is also in single digits cpu utilization MOST OF THE TIME when it's set to stocks.
but try it with the ES and NQ, full screen, after a fed announcement, then you will know what i'm talking about.
 
ArchAngel - it wasn't the result of a lousy programmer. The programmer was someone who I know personally, and has been using both C++ and VB for many years. We're talking about someone who has been programming since the early days... 20+ years and has a Master's Degree in Computer Science. The code was very good. The problem was with the language... but only in a situation like this does it become a problem to the point that you must use something like C++. For normal everyday programming of small applications, VB is fine.
 
I agree with Modulus. Only those who know only VB will say that VB can do pretty much anything. Realistically though, C/C++ has its advantages over VB and that's in speed.
 
You must log in or register to reply here.
Back
Top