as above.Also, as with visual studio .net, you can know program using whatever language that you are comfortable with (as essentially, they will produce same base code (I may be mistaken here)), do these advantages remain? How about if we compare C++ with Java?

You're right, these days, there's almost no difference because VB, C++, C# and a pile of languages can now compile to a common format.These days? .NET is the way forward, because the code then supports over twenty languages, including every important language you can name. For code that compiles to MSIL, the performanceis similar for each language. I noticed some performance improvements with heavy numericalstuff, like BLAS III. It would be quite easy to plug in highly optimized BLAS III if required.After spending the past six months with C# (a new language, similar to C++ in appearanceand performance and with ease of use like VB) I categorically recommend it for anything infinance. It integrates with Excel beautifully, has a fantastic development environment, a freecommand-line compiler, if you prefer this, and as of early this year, is a European standard.We have developed a derivatives library with over 200 classes in C#. The DLL builds in about5 seconds compared to 5 minutes for the ISO C++ version. There is very little difference inperformance.

After spending the past six months with C# (a new language, similar to C++ in appearanceand performance and with ease of use like VB) I categorically recommend it for anything infinance. It integrates with Excel beautifully, has a fantastic development environment, a freecommand-line compiler, if you prefer this, and as of early this year, is a European standard. >>I've been toying with the idea of migrating (from VB and some basic stuff I've done in C++) to C# on the .Net platform - James, I think you've sold me on the idea. Do you have any book/website recommendations? My level is very good VB, OK-ish C++. All help appreciated!

thanks james. alas, i've no experience in visual c++ or c#. i've heard c# is so similar to java that it seems that microsoft has copied it wholesale from sun. it shldn't be that difficult for me to pick up c# as i've a java background it's now time to get a job though

The recent version of VB is also worth looking at. There have been major changes to the VB grammar that make it more or less equivalent to using C# or any of the other languagessupported by .NET.One of the nice things is that everything compiles down to a standard exe or DLL and it'spossible, if required to call other languages *without* having to write endless wrapper code. Some banks insist on using languages, such as SmallTalk and Eiffel and to support these without effort is a compelling argument for us. There are about 20 languagessupported in this way.Have fun.

James,You seem to have some experience in this young field of C# and .NET. A lot of option models are written in VC++ and the also make use of third party pricing products also written in C++ implemented as DLL's.I do not see re-writting these a a real viable option, so my question is what support does the .NET platform have for old VC++ programs and DLL's?And if they can be deployed on .NET, what support does it give in bugs fixing and enhancing the old stuff (I never thought that I would refer to C++ as old stuff).All,A more general question, what is the level of take up of .NET (C# & VB) in writting derivatives pricing applications? is it front-office only?Thanks,Mexx.

I am very sorry if my question is a bit basic but since I have never officially met with .NET I need to ask whether its the same deal with VS6 as in software you run locally on your machine or a service offered by MS.rgds,Dimitris

I am very sorry if my question is a bit basic but since I have never officially met <img src="i/expressions/face-icon-small-smile.gif" border="0"> with .NET I need to ask whether its the same deal with VS6 as in software you run locally on your machine or a service offered by MS.rgds,Dimitris >>Dimitris, it is the same deal as VS6.I wonder how widely spread is the popularity of VS .NET is in Europe and USA, especially in the field of financial engineering.

Thank you effendi rgds,Dimitris

Hi Mexx,For the past ten years, I've mainly used C, C++ and VB/VBA/Excel like you.You're right, there's not much code in C# at the moment.Don't worry that few are using it at the moment, it's the next version of VC and it's in the next big release of Excel. Goodbye VBA as we know it.Things are reaching a climax in the OTC world, because margins are tiny,and processing costs are so high that firms are having to move to a standardmodel. Using a standard OTC trade model, such as FpML and *compatible*software languages will have a huge effect.I think those dusty, proprietary DLL's will fade away...because as banks movethe back office processing to FpML, the front office analytics also has to move,because the product definitions are *way too complex* to map. Cheers,JBt

JBt,Thanks for the info, it looks like C# and .NET will be one to watch in the future. Just debating how much time I should spend learning C# as opposed to learning more Maths Finance.Thanks,Mexx.

JamesBattle >> After spending the past six months with C# (a new language, similar to C++ in appearance and performance and with ease of use like VB) I categorically recommend it for anything in finance.Is C# really that nice? I'm serious - I heard some good things about it, and started to have a look - but I'm a chicken. I got scared off by the apparently endless sequence of keywords, and a sneaking feeling that as I learnt more it might get worse - unfortunately I couldn't shake off first impressions which were that it had the more repellent aspects of Java and VB. I still feel that it sounds attractive especially for XL and COM, so I guess I need to take the plunge...

I've never heard of FpML. Will try to get more details about them. i think link this shld be the best place to start

<< <i>JamesBattle >> <i>After spending the past six months with C# (a new language, similar to C++ in appearance and performance and with ease of use like VB) I categorically recommend it for anything in finance.</i>Is C# really that nice? I'm serious - I heard some good things about it, and started to have a look - but I'm a chicken. I got scared off by the apparently endless sequence of keywords, and a sneaking feeling that as I learnt more it might get worse - unfortunately I couldn't shake off first impressions which were that it had the more repellent aspects of Java and VB. I still feel that it sounds attractive especially for XL and COM, so I guess I need to take the plunge...</i> >>JamesBattle, I don't want to raise the pressure on you any higher <img src="i/expressions/face-icon-small-smile.gif" border="0"> but I'd love to hear more about C# as well ... not just in terms of building model libraries but also, if possible, how it compares to VB in terms of RAD type applications.

FpML stands for 'Financial products Markup Language', which is an XML standard for OTC derivativesrun by ISDA (International Swaps & Derivatives Association) which is the trade body for derivatives.In summary, FpML is a textual representation of OTC derivative products, initially designed for inter-bankconfirmations (still today, OTC derivatives still use fax/phone for confirming these things). Because they're OTC, the exact definitions of the products have varied between institutions. i.e. it hasn't been a technologyproblem so much as getting everybody to agree on what the products are. Beware, the products are more complicated than in most books (e.g. it's possible to do things like embed. a Bermudan into a swapto make it callable, or to make the fixed coupon step-up/down, amortise the notional etc).Up until now, banks have implemented FpML by mapping the XML into their own proprietary object models.The problem is that the products have become so complex that, unless you've already got an incrediblyflexible model, it's impossible to round-trip the deals without losing stuff, mis-pricing or getting the riskwrong. You can be sure that a lot of banks will be mis-pricing stuff all over the place once the systems are live.The only smart thing to do is bin the old stuff and rearchitect around an OO version of FpML. (shameless plug: this is the work I do).For quants, it's an exciting time because there's not a single vendor who has pricing and risk built aroundan FpML model. By this I mean, given an arbitrary deal on the wire, produce a price and risk. Don't believe salesman when they tell you, you can plug in there proprietary DLL to support FpML...with the deals becoming commoditised, the margins will go to zero and hence the model has to *really* good just to avoid losing piles of money.