> How do you find VB.Net compares with VBA for speed?
Doug, so far I have clocked only the TestMinLBFGS subroutine: on a Core2Duo 2.9 GHz PC, it takes about 45 ms to execute on the first run and 31.5 ms on subsequent runs. In my pursuit of optimization with constraints, I have also ported the ALGLIB's MinASA module. I have a reference setup in Excel and compare the MinASA results to those in Excel to make sure everything works fine. While I have not clocked MinASA yet, I can tell you that it is many times (100x?) faster than Solver in Excel. That's good enough for me.
> Is it fully compiled? Have you compared it with any other languages?
I have been wondering about the VB.NET code optimizations. There is a notion of "compilation", which supposedly translates the VB code to the CLR code (common language runtime). So, unless expression/subroutine/global optimizations are not possible in a line-oriented BASIC-like language, I would venture that the performance will be almost identical with what you would get with C/C++.
> Do array bounds default to double if you omit the "I" suffix?
Not that I know of, which is why it should be OK to state "x(0 to 1)" instead of explicitly "x(0I to 1I)".
> Are you suggesting one function per module?
There are pros/cons of having one function per module. The main pro is optimization of the program size: the classic principle is that you statically link only what you need; re: standard C libraries with only one function per file (a typical linker has a file granularity, but modern linkers may be smarter). Another pro is logical containment, e.g., I would like to have all functions related to, say, MinLBFGS or MinASA in one module and that module should not contain any other functions (this is exactly how ALGLIB sources and tests are partitioned).
> I won't comment on the use of classes; that's another area where I really need to get up to speed.
To simplify things, a class is a module with private data (members in C++, properties in VB.NET) and functions/subroutines (methods in C++, members in VB.NET) that facilitate access to and manipulation of this data. The basic principle here is encapsulation; think of it as a glorified structure. AFAIK, VB.NET supports simple inheritance (from one base class, just like in Java, but not multiple classes, as in C++). It also supports polymorphism, the 3rd tenet of object-oriented programming: you can have multiple identically named functions that accept slightly different parameters, so that their "signatures" are different; at compile time, the right function is called depending on the type of args you supply.
> Any comment on how VB.net compares with other languages for interaction with Excel (and other programmes with built in VBA)?
As I mentioned, ideally the entire ALGLIB should be in a DLL, so that all these useful tools could be invoked from any language running on the CLR. This way, Sergey & Co. would have to produce only the interface ("header") files for each language, and not translate the entire ALGLIB to all languages. Much less work, and if the DLL is developed in C++, it will be as fast as it gets after translation to the CLR.
How things would be partitioned inside of this DLL can be a matter of debate. Personally, I like classes because that is a more modern approach than modules and it will support future extensions through inheritance and polymorphism (if, like I, you have been around for a while, you may recall the evolution from Pascal to Modula2 to C++/Java/etc.). For interaction of Excel VBA with a DLL, see:
http://support.microsoft.com/kb/317535