As any body started using C#.NET for financial packages yet?; whats the demand like, or how popular is it likey to be?AqiqVal

I read that for FPML protocal product --- OTC Objects™ - FpML Framework for Microsoft.NETiron bark implemented .net & C#. check at http://www.ironbark.co.uk/I heard that CSFB,Chase are starting some projects on .net & asp.net--Rajagopal

when did you hear that CSFB was doing .Net work? has this been in the last 6 months or before? i ask because it seems to me that they are ditching all their old COM based initiatives and heading down the EJB path. what kind of projects were you referring to anyway? (I.T./Systems projects or research projects)

It's important to make a clear distinction between 'old COM stuff' and .NET. COM is finished, because C# and the other .NET languages have made it redundant.It's true, a lot of institutions are starting to use EJB - I think the market willend up split 50/50 in .NET and Java and that's not a bad thing because itmeans that MS will continue to improve their stuff.As a purist, I think that Java is preferable to anything COM based, butJava is Java is Java and using Java for quantitative finance is not that great - the performance sucks big time and so does memory usage. Comparing Java to optimized C is a joke and remember that it's a mess to use C/C++from Java.There is also the very real issue that Java has no support in spreadsheets and nothing like VBA that a lot of traders love and use!!Using Java in a banking system is difficult because it usually involves tossing everythingnon-Java (Java guys love everything 'pure' Java which seems stupid - why shouldwe have to bin all the great C/C++/VBA code and then get terrible performance?On the other hand, with C# there's no problem hooking old C/C++ code and theC# code is interoperable with 20 languages, including oddities like SmallTalk andEiffel that are still used in some banks... I know of major banks that use Eiffel and SmallTalk in serious quantitative work.C# Demand? well it's still small (sigh), but I'd rather be developing a product based on a growing code base, than a dying one! And remember that there is a swarm of VB/VBA programmers on the way.P/S An Ironbark is a bloody great tree

i think jamesbattle makes good points.my intention wasn't to promote ejb, it was just to find out what rajagopalp was referring to with CSFB and .Net. afaik, there have been no recent projects (with any kind of a profile) going on in .Net over there. (but i could be wrong.)

Kapital,I heard from one of my friend who works for CSFB in FI , that his colleagues are doing on C#..etc may be they are doing their own R&D.may not be real projects.OK.raja

yeah, could be. i got curious and did some asking around: doesn't seem like there are any i.t. dept projects going this way, but anything can happen in the research area. given both the f.o. and b.o. addiction to excel, at a minimum they have to be preparing to do some work in .Net. it only makes sense. ( ref to the bottom of jamesbattle's post about vb developers coming on board.) thanks for the reply.

According to the following news release, in fact CSFB are moving to .NET in a big way:http://msdn.microsoft.com/vstudio/produ ... ies/csfb/I know of a lot of banks moving to .NET as a strategic technology. While Java is nicefor some applications, unfortunately it's never become a reality to mix with otherlanguages and after 5 years still has a terrible integration with the apps that tradersuse, e.g. spreadsheets, VBA etc.As languages, C# and Java are quite similar, but using C# means that the librariescan be used from about 20 other languages --without having to write wrappers--which is a huge advantage.JBt

QuoteOriginally posted by: jamesbattleIt's important to make a clear distinction between 'old COM stuff' and .NET. COM is finished, because C# and the other .NET languages have made it redundant.James,I'd say that from an IT perspective, COM is very far from dead!! Think of all the f.o. and b.o systems, both commercial/ in-house which have been implemented an integrated over the last 5 years (in your typical, large/medium-sized financial institution).I think most of the existing COM-based systems will have to be maintained for quite some time. The decision to replace one system with another depends on many factors such as integration with legacy systems, multiple database back-ends, business partners etc. The technical benefits of .NET from a developer's point of view, will in many cases, be overshadowed by 'business' or integration issues.Now, keep in mind I'm talking about enterprise systems, not a stand-alone desktop application with limited interfaces to other systems.I think a lot of IT departments are very cautious about moving to .NET, especially since some of the major financial software vendors are a bit slow on the uptake, and a few have barely entered the COM age. Also, I think a lot of people are still figuring out the risks/challenges involved in with .NET/COM Interop services. There's also the question of training developers in .NET - it doesn't happen overnight.Anyway - this view is based on what I've seen around me, I'm sure some IT depts. are way ahead on the .NET curve.

I also agree with PinballWizard.COM is not dead yet. It might not be used as much in the .NET world but it will still be used. COM is the only way people can use their legacy DLLs. I cannot see companies rewritting them in .NET yet. Jamesbattle you are correct when you say, "It's important to make a clear distinction between 'old COM stuff' and .NET COM objects." They are completely different from each other but luckily old Billy gave us imptlb.exe which makes using COM object between the two very easy. Us the programmers never sees the difference.Who knows even if .NET will take off? .NET has been in production i.e. officially supported and sold by M$ for just over a year now. I bet less then 5% of the industry has took a serious look at it yet. Most likely some features in .NET will become popular while others just are ignored.Just my 2 cents. You guys think anyone will ever become richer then Billy? Probably not in our life time. Has anybody looked at the past millionaires of the earily 20th century and calculated what their net worth would be today?

Maybe I should be more specific. I agree that COM is not dead. The point is that you can writre COM compatible software in C# and other languages, if you choose,without having the old language limitations.Sure, some banks have not entered the COM age, but banks do not necessarilyhave the smartest collection of people in the world either, though some big, globalinvestment banks would like to think so!Some banks I know are still using VAX/VMS in a big way and if you look hard you'lleven find some using COBOL.PS/ .NET supports Fujitsu's COBOL language.

>...and if you look hard you'll>even find some using COBOL.look hard? man, it's everwhere!

That's my point! How many quantitative finance packages support COBOL ...By using .NET you *automatically* get COBOL support and about 20 other languagesincluding COM. The fantastic language interoperability is the thing that made us switch to .NET, notany of the crap going around about web services and the internet.Another thing that people are just not getting is that .NET does NOT mean you have tobin your C++. C++ works fine from and with C# and the new VB.

Also check out the new QuantLib port to .NET:http://jens-thiel.de/finance/quantlib/homeThere's a *lot happening* with .NET/FpML in quantitative finance - ask the authorguy about the banks that hit his site...

Quoteif you look hard you'll even find some using COBOL.At my last firm, the billing/timesheet management system was still written in GWBasic!