Has anyone tried writing financial software application or tools in the .NET framework using C# or VB.NET?I have been working on the .net platform for the last one year and find it to be extremely powerful in terms of speed of development and usability without sacrificing on the speed of the application.Has the financial industry looked at C# as an alternative to C++?I presume one has to be highly skilled in C++ to be productive and to churn out code at a fast pace. I would like to hear from the practioners about the viability of C# and .net to develop fin s/w.nAnooK

Somewhere else on Wilmott

I've been developing solidly with C# for the past year, after almost ten years with C++, C, COM etc.The productivity improvement in using C# over C++ ????? at least 100%. Maybe 200%. Compile timesare closer to 1000% .... and code performance is still similar to C++.Example: My company developed a huge COM/ATL library to test SwapsWire's electronic dealing platform.Implemented in C++/ATL/COM tyhat took 10 minutes to build. Since then, we have developed a productised implementation with twice the functionality and it builds in 5 seconds!!Being able to rebuild a large (>100,000 lines) of code in 5 seconds opens all soughts of possibilitiesand improves your productivity INCREDIBLY. Besides performance, there are some nice language features,including a new type called 'delegate' which is basically a function pointer - but type-safe and a REAL typecompared to a memory address or a void* pointer or a pointer to a function blah blah.Without wanting to degrade from the great work in projects such as QuantLib, the fact is that with developing huge C++ frameworks, you spent a large proportion of time on technology, rather thanimplementing nice financial maths (trying to understand the error with a deeply nested template withten parameters, rather than doing finance !!!!!)But is it viable to develop in C# in a small company ???? Develop your stuff in C, C++ and you will spend all of your time porting and implementing Excel addins,COM wrappers and other shit that just IS NOT INTERESTING.Develop your stuff in C# and you get IMMEDIATE support for over TWENTY (20) languages, includingC++, C#, VB, COM, Eiffel, SmallTalk, Java, .....Besides the language, the IDE has some incredibly smart features that digging quite deep, will amazeyou how they even work. Play around with CodeDOM and you'll know what I mean.This is a great piece of work by Microsoft and deserves a really hard look.There are of course, still huge barriers to taking really productive technologies in big banks, becauseinevitably you have to support the 700 Excel addins, each which takes 20 parameters (no jokinghere...) and besides which, if you have'nt noticed, the City is back in that cycle of sacking goodpeople to make bald investment wankers on the fifth floor happy...Enough said.

<< <i>Without wanting to degrade from the great work in projects such as QuantLib, the fact is that with developing huge C++ frameworks, you spent a large proportion of time on technology, rather thanimplementing nice financial maths (trying to understand the error with a deeply nested template withten parameters, rather than doing finance !!!!!)But is it viable to develop in C# in a small company ???? </i> >>I'd argue that .Net is ideal for a small company (such as mine!!!) on the basis of limited legacy.<< <i>Develop your stuff in C, C++ and you will spend all of your time porting and implementing Excel addins,COM wrappers and other shit that just IS NOT INTERESTING.Develop your stuff in C# and you get IMMEDIATE support for over TWENTY (20) languages, includingC++, C#, VB, COM, Eiffel, SmallTalk, Java, .....Besides the language, the IDE has some incredibly smart features that digging quite deep, will amazeyou how they even work. Play around with CodeDOM and you'll know what I mean. </i> >>Don't forget that the SDK includes a compiler too - you don't actually need the IDE.For small companies (and departments that act like small companies, zero budget affairs) throwing a grand on the IDE for a punt is a bit too expensive.<< <i> .. people to make bald investment wankers on the fifth floor happy... </i> >>It's ok, I've just seen him sailing past the window quite quickly. Unfortunately *after* some colleagues were shown the door.My 2c : C++ is cool and quick sure, but slower to develop in than VB. VB is quick to develop in, not *that* slow to run, but you have no real control or ability to optimise (those damn COM wrappers get in the way). C# is a damn good middle ground - at long bl**dy last!!!

<< <i>The productivity improvement in using C# over C++ ????? at least 100%. Maybe 200%. Compile timesare closer to 1000% .... and code performance is still similar to C++.</i> >>Show me proof!<< <i>Implemented in C++/ATL/COM tyhat took 10 minutes to build. Since then, we have developed a productisedimplementation with twice the functionality and it builds in 5 seconds!!</i> >>Get real dude, no way in hell this is true! Also learn how to SPELL! Maybe thats your problem! If you know what you are doing you can optimise the compiler. Also, .NET includes several languages. C++.NET is one of them. From what I have seen so far .NET has some coolstuff. The question is will it be accepted by the industry and how long will that take. Remember a beta version of .NEThas been around for three years now. The release version has been out for about a year now. The beta version andthe release version are completely different. You cannot just take code from one and compile it on the other without modifications.The myth that you can develop products quicker and better using VB, C#, Java etc. over C/C++ is a myth. A good C/C++ programmer can create the same applications in a similiar time frame. You have to remember that most applications are multi-threaded and use system resources like shared memory and sockets besides having a GUI interface. You can do everything in C\C++ which you can do in any other languages plus some. The opposite is NOT true.Every language has good and bad things about them. Every language was created for a purpose. If you have good softwareengineers working for your company they will know when and where to use certain languages. Sometimes you have a choiceon different languages to use and then you base your discussion on the experience of your programmers. Since there arealot more VB then C\C++ programmers, people create applications using VB. The best VB programmers are the ones who canalso program in C\C++. I will take a dozen of them over a hundred just VB programmers anyday.The common runtime (CRT) environment also has problems. Every language which is part of .NET uses it. C++.NET is the onlylanguage which the programmer can deside if they want to use CRT or native code. Any application which is created using CRT can only run on machines which have the .NET Framework installed. There are still alot of machines out there running Win95 sothis creates a problem since Micro$oft doen't support updates for it anymore. CRT also has good things about it. Being able to usecode written in one .NET language easily in another .NET language is a big plus.And for all you non-believers, C/C++ is still the almighty god of programming languages. If it wasn't Micro$oft would be releasingtheir newest OS written in VB or C# pretty soon because you can create anything so fast using it, and have the same or betterpreformance issues! SURE RIGHT and pigs can fly!

The best VB programmers are the ones who canalso program in C\C++. I will take a dozen of them over a hundred just VB programmers anyday. >>Agreed.

mholm,Sure you can do everything you could possibly want in C/C++, but so can you in x86 assembly. Does that mean that one should necessarily program using assembly - of course not. One may wish to program some critical piece of code in assembly for performance reasons, but not a complete Win32 application (even though it is feasible). It has something to do with what jamesbattle calls "productivity improvement". The actual productivity improvement (using .NET) for you may very well be close to 0% ... I mean it does sound like you're a superb programmer after all, but for others (myself included) it is definitely > 0% !I really don't understand why people get so religious about programming languages (you did mention the 'almighty god of programming languages' ) I mean, any language you choose is trade-off between one thing and another. I'm sad to say that, at the end of the day, the end-user really couldn't care less what you code in... as long as it works reasonably well and not too complicated to use, it will do. That's why those 700 Excel add-ins are still around.Lastly... .NET will most probably be very successful. We're talking Microsoft here. They have the monopoly and will do just fine. I have no doubt 'unmanaged' C++ code will do very well too... after all, there are plenty of legacy programmers around

And for all you non-believers, C/C++ is still the almighty god of programming languages >>This is precisely the reason why .NET will work. If you feel C++ is the mother of all languages, then go ahead and program in it. Humble coders like me will program in whatever language they feel they are more comfortable and most importantly productive in. Our programs will still be able to talk to each other, I would still be able to inherit your all powerful , all conquering Objects because of CLR. No more of those flamewars about "My language is better than your shitty language". Infact the basic philosophy about .NET is that companies and corporations will no longer be looking for a C++ expert or a Java guru or a VB wizard, rather they would be hiring people with domain expertise and let them program in whatever language they want to.Although I have my reservations about how well CLR ,in it's present incarnation deals with unmanaged code but there is hope. It's just been a few months since the release of the first version of .net and things can only get better. It took Java almost 3 years to become accepted at the enterprise level.Please, let's not start a flame war and rather have a meaningful discussion about the pros and cons of using C# in the financial domain.PW I completely agree with you that MS will do anything possible to make .NET a success, "Resistance is futile" . nAnooK

Proof - sorry I don't enter into competitions. You sound like a C++ guru and I'malways afraid of them. Your claim about BETA vs Release of .NET is not true. Except for some trivial changes thattook our company less than a minute (changing the name of the System.Xml namespace)everything compiled and ran perfectly. I am talking about over 100,000 lines of code.I'm sorry, I don't the time or interest to prove this to you! In contrast, having ported dozensof similar sized libraries between C++ versions (HP-UX, SGI, Dinkum) this has sometimestaken weeks. Go look at the config files for SGI and you might understand this - thosemacros have been there for YEARS.Your claim about being as productive in C++ is not based in reality. If you really understandC++, i.e. the grammar you'll appreciate that C++ is a horrible mess. So horrible that it'sone of the few languages, in with FORTRAN that has a grammar that even today isalmost impossible to write a good parser for. Go play with YACC/ANTLR/JavaCC and findout - I'll speak to you in ten years time.Except for the STL, C++ does not really have anything uniquely impressive. If you haveunderstood the algorithms in STL, you'll soon also appreciate that they can be easilycoded in virtually any language - nopthing special about C++ here! Some C++ programmersthink a std::map is something special for the 'big C++ guys' - in fact it's just a red-blacktree that can be coded in any language you like.The timings are based on real OTC derivatives consulting work for clients for which I haveno intention of providing details.In summary, yes C++ is a good language as FORTRAN was for a long time. I use to be passionate about both. By the way, have you ever run the LINPACK benchmark usingC++ .... C++ is not the great numeric language you claim.I don't appreciate your 10 C++ programmers against 1 VB guy. Personally, I use whateverlanguage the client desires and which is most productive and profitable for my company.I don't work for Microsoft either.The problems in C++ will not disappear any time soon, because the grammar is a mess andis beyond most automated analysis. Go check why it fails LR(1) and you'll appreciate why there might never be anything better than what exists now. Also let me know, which compilersactually support the complete grammar -- NONE.Shared-memory, sockets etc. are nothing unique to C++ and you'll find much better supportin either Java, C# and VB.net - have you tried this ?? or are you a UNIX guy who sits withStevens' book?

One more thing. We do a lot of C/C++ work on UNIX because **clients like it**. INreality, there is NOTHING in C++ / UNIX that can't be written in C# or VB.net. Please provide one (1) sample?Cheers,JBt

Here is one for you an Operating System. When will a company create one using VB or C# which will be widely used throughout any industry? Maybe Micro$oft's BOB OS was created using VB and thats why it was so successful. Do you even remember the BOB OS?Another problem with C# and VB.NET is Win95. Win95 does not and will probably never support the .NET Framework. Several companies around the world including home users still use Win95. McDonalds is a perfect example. 90% of McDonalds computers run Win95. My sister-in-law is a programmer at their head office. The way the economy is currently I cannot see all of these companies running out and buying new machines with the latest Micro$oft OS. If they did, it would certainly help the world economies.Let me throw your question back at you. Give me examples which you can do in VB.NET and C# which you cannot do in C\C++.You need to read my post again. I didn't say that .NET was shit and C\C++ was gold. I believe I mentioned good and bad things about .NET. I was only showing why C\C++ was still the almighty God of programming languages. NOTE: A release version of .NET has been out for about a year now.You cannot compare Assembly to C\C++ idiot. Just like you cannot compare Binary to Assembly code. They are like apples and oranges dude. C\C++ is a higher level language just like Java, VB, C#, etc..All I said was that you couldn't take code written in the beta version and compile it in the release version with making changes. I didn't say anything about how long it will take to fix it or what changes needed to be made. I consider changing the name of the System.Xml namespace to be a big thing. It would be similiar to them changing the name of "stdlib.h or windows.h"<< <i>I don't appreciate your 10 C++ programmers against 1 VB guy. Personally, I use whatever language the client desires and which is most productive and profitable for my company. I don't work for Microsoft either.</i> >>You need to learn how to either read or write dude. You need to read where I talk about good software engineers.<< <i>Shared-memory, sockets etc. are nothing unique to C++ and you'll find much better support in either Java, C# and VB.net - have you tried this ?? or are you a UNIX guy who sits with Stevens' book?</i> >>I never said that they were. I was using them as an example. Can you truthfully tell me that you can use shared memory, sockets, or threads as easily in VB as in C\C++. What exactly do you mean by 'much better support'?Just to let you, I have bought books recently on the following topics. ASP.NET, C#.NET and C++.NET. If I am interested in something I usually try to find a good book about that subject. The ASP.NET book is the book I hate the most because it was written for the beta version and the code examples don't work. Thats a big "pet-p" of my. Looking at code in books which don't compile. By the way I do own Steven's book.I also like working with pointers and controlling my own memory managemant. I personally prefer AVL Trees to Red-Black Trees. Thats why I created my own class. I do like STL and use it when its needed. But when I need to have something fast with very little overhead I cannot use STL, I need to use my own stuff which is optimized. I do not want Micro$oft doing everything for me behind the scenes. If we let them how can we optimize our applications. Don't you think there is a cost in performance when Microsoft lets you type ten lines of code to create applications where it takes more lines in another language. In the financial industry speed of the programs is VERY important. I create large n-tier applications which takes months, years or will never be completely finished because we are always adding new functionalities to it. If you are creating simple one function applications or excel add-ins then by all means use VB because you will probably create it faster. Have you ever tried to use Micro$oft's Chart Control which is an Active-X Control in C\C++. If adds like a million classes to your project. I created my own chart control using four classes which is a hell of alot faster and can keep up with any real-time data sent to it. Mine is much simplier to use also.When I use C\C++ above I am also including the MFC, SDK and C++.NET libraries also. Sorry if I offend any Linux\Unix people.

mholm,re: You cannot compare Assembly to C\C++ idiot >>There's really no need to be insulting - it's hard enough to communicate on a forum.The point I was making is that I could write a full-featured Win32 app using assembly and the Win32 SDK however it would not be an efficient use of my time. I could also use C and the Win32 SDK to write the same app. However I am not inclined to do so, as I feel I'd waste a lot of time re-inventing the wheel. By no means do I want to play down the importance of C, but like any other language or programming paradigm it has its own strengths, weaknesses and it's own place in the developer's toolkit.If I could I would love to spend my time using just C and optimizing every last bit of code, that's why I sometimes think I should go into game programming... fine-tune the best physics game engine ever built Anyway - who knows where .NET is going to go ... we should re-visit this thread in a couple of years!Cheers.

mholm,Thanks for the lively debate. Great stuff!--Back to the topic--The original question was who's using C#/VB.net in FINANCE. By FINANCE, I mean derivatives,equities, bonds and other interesting stuff. In the past five years I have not seen a single W95machine in any major bank. I appreciate that they might still be used at home, but who cares!!W95 is an old operating system, going back to DOS, and I can understand why MS don't supportit for .NET. For example, .NET has very powerful networking code that would be nasty, if notimpossible to support on W95.On the McDonalds point - I thought they sold burgers, not Bermudan swaptions? Without wanting to insult them (great burgers) I've never seen them doing anything with derivatives -I might be wrong and if you work for them, maybe things are about to change!There's nothing in C# that (in theory) you can't do with C/C++. I use C/C++ all the time. That'snot the point. In fact, the grammar of C# offers very little other than a combination of Java andC++ with a bit of syntactic sugar thrown in. The point is that it's a great language for finance,BECAUSE:1) The IDE is incredibly productive, similar to VB2) The performance is great3) Except for generic programming, i.e. templates, there's everything you need4) It allows writing apps with fewer bugs. 5) Your apps run with 20 languages, rather than just one. I appreciate that it's possible to write COM/Python wrappers etc, but why bother when it comes for FREE in C# ?6) It's going to be a major force in finance VERY SOON. The Beta had 4 million downloads!Why do you prefer AVL over red-black? Red-Black is preferable for a pile of technical reasons I won't go into here. I don't recommend writing an AVL or Red-Black implementation for productionuse in a bank or anywhere else. It's way too complex and has no payoff. The downside is thatthere will be a VERY obscure bug that will be virtually impossible to locate.The SGI/STL is exceptionally good, has been tested by thousands of people and is free. Theonly time I'/ve written anything this complex in a bank, was when I ported a red-black implementation to MFC, so that existing MFC code could get significant performance improvementsover the old CMap.I appreciate you concersn with large programs. That's why it's important to use a languagethat allows things to be compiled VERY quickly. Dude I'm not kidding you, the same versionof a large class framework will take ~10 minutes while the same in C# will take to seconds.Finally, if you like Stevens' books (sadly there will be no more) then you need to take a lookat C#. Trying writing the ping program in C and then compare it to C#. This should convinceyou that it's possible to do all the same things you used to do with UNIX.P/S I recently purchased a nice Sun Blade box to develop some financial stuff. Fact: afterdeveloping in C# for the past year, the Sun stuff has been canned.Best regards and have fun.James Battle

For UNIX guys, I just noticed that there's now a complete version of the .NET infrastructure(including all source code) for FreeBSD. It's already had 30,000 downloads since the release.It's becoming clear that this is going to be a major, if not THE major language for this decade.http://msdn.microsoft.com/library/defau ... 2.aspJames Battle

There's also an open-source implementation 'the mono project'