I completely agree with Jamesbattle.The purpose of this thread is to discuss the feasibility of C# in the world of finance and for practitioners to share their experiences.Let's not start arguing about whether C# or C++ is the best invention after sliced bread. Definately, C++ has lots of good uses and is a necessity in a lot of areas, otherwise it wouldn't have survived for so long. But change & evolution is inevitable, just because people have been writing applications in C++ in the past doesn't mean in 2050 programmers would still be coding in C++.nAnooK

Just some comments regarding .NET and Unix:What MS released for FreeBSD isn't "a complete .NET platform", it's just the CLR, not the classlibrary, i.e. not really very useable for serious development, but a nice thing to have for research and testing.I am myself a die-hard FreeBSD user and thinks it is a bit funny that MS released the version for just FreeBSD, it once again shows that FreeBSD probably has a larger role in Redmond than most people realize (and they probably has at least parts of a classlibrary for FreeBSD too - what else than C# would they use to finally move away from FreeBSD at Hotmail? ).The Mono project on the other hand has a goal to implement a complete .Net platform (ASP.net and the works). Sounds like an interesting project.I find .Net an interesting technology, just as I found Java some years ago. I never got hooked on Java (even though I learnt it and sometimes use it), let's see how .Net will affect me. It might finally get me to actually learn some Windows, I missed that train years ago and haven't yet gotten around to really learn it (besides the pointing-and-clicking ) I find it likely that C#/.Net will be well suited for Finance applications with ties to Excel and other such products used by end-users being easily implemented.

Apologies if this has been covered here or elsewhere, but can anybody explain the difference between VB.Net and C#? Or are they really the same. And what about C# and Java, are these fundamentally the same?

(I'm biased against VB.Net)All the Dot net langauges are effectively the same because they have to be fitted to the same underlying 'organism'. C# was developed to be the language of dotnet, but sometime it's difficult to know which came first .Net or C# - I don't actually think either did.C# is quite C like in form, VB.Net has had to undergo quite a transformation in form in order to fit the framework. Due to it's origin, for me, C# is the way to go.VB.Net looks horrible and would confuse me if I tried to take my VB6 skills to it. The UK MS guys joke at the Events that VB.net with a semicolon is C#!Java and C# are quite similar, and I don't think it's worth starting a debate about one over the other - it gets unpleasant too easily. There's also a Java like language called J# for the .Net framework.My own phlisophy has been that I believe that C style languages are becoming the mainstream defacto standard now* and as there is little difference between the code that is actually generated (there are some things in VB.net that you can't write in C# and Visa versa I understand) there is no point in arguing too much - most of us also have to be proficient SQL and network etc programmers also without ven mentioning the Risk/finance work that we are paid for!!!!The big thing for me is that the framework is proper OO, whereas traditional VB only went so far. I started with Borland C, dropped the ball, and started from the beginning again with VB and now have some C++ too, I'm not that confidant with the more esoteric features such as templates but use them very occasionally when I feel that they are reasonable.Langauges are a personal choice - I like the way C code is written - but as the underlying intermediate language is the same make your own choice - changing between them should be easy.Good luck.OTM* because the development of the traditional VB languages have ended, although many programmers like me are quite happy with them - I guess I'll be able to get a .Net app going as quickly as I can a VB in a little while.

Well said. I view VB.net as a migration path for VB programmers to C#/C++. Thereare way to many of them to be ignored.In the end, the most important thing is not how big your language is - it's what you do with it!! It's possible to write great finance apps in any language.As a company, we've totally swapped to the .net languages when developing finance stuff for the windows platform, because:- customers are starting to demand it- it's easy to use- it's 'efficient enough'- we can develop the same code much quicker than before

I've been developing a modeling and trading framework for a small company. Initially I started it in C++ but abandonded C++ in favor of .Net languages because of the development speed. I still have some unmanaged C++ to interface to datafeeds, some legacy code and third party packages. I haven't made any direct performance comparisons between C++ and .Net versions because I've changed the architecture but computing time is much cheaper than my time.OK, I couldn't stand not responding.>>>Give me examples which you can do in VB.NET and C# which you cannot do in C\C++.dynamic class loading / reflection -- OK, sure you can do it, but it'll take more than a couple lines of code, it's a pain and you'll be using OS-specific libraries.>>>>The myth that you can develop products quicker and better using VB, C#, Java etc. over C/C++ is a myth.Bruce Eckel (the author of Thinking in C++) points out in the introduction to Thinking in Java that developing in Java takes "half or less of the time that it takes to create a equivalent C++ program".

Someguy2, I can echo just about every word you said, except I am worried about the speed if Microsoft Intermediate Language is being interpreted all the time. How does that work exactly? And I also have legacy applications that use "regular" DLLs such that, as a beginner, I am puzzling over the fastest way to get them to talk to my .Net assemblies.MP

The MSIL does get compiled at some point. A JIT (just in time) compiler compiles the code the first time a method is invoked during a run of the application. From that point forward (during this particular run of the application) the compiled code is used. There is also an option to compile code at deployment time but I haven't looked at that (ngen is the name of the tool).For calling DLL's the "managed extensions for C++" provide a relatively easy way to interface to Win32 DLLs. Typically you end up writing wrapper classes that do the memory management for the unmamaged DLL. The online Help in VS.net has a bunuch of information on this. If the DLL exports a COM interface it's easy to wrap the COM interface in .Net and call it.

I really don't think performance is an issue with C#. The truth that few C++ programmerswill actually tell you is that C++ *never* became a serious language for numerical work...Without taking extreme care, avoiding hidden copies etc etc. BLAS 3 performance isnot great compared with C.Of course, at this point I'm expecting some C++ guru of 6 months to shout me down,but when the shouting comes, please provide real benchmarks, i.e. LINPACK for yourC++ library!For C# it is possible to call low-level optimised BLAS and other numerical algorithmsseamlessly or to implement them natively in C#.Comparing the .NET framework to the C++ standard library is no contest at all. .NETprovides over 7000 classes, while C++ STD/LIB basically is a pile of collections and afew dozen algorithms. (Admitted templates are sometimes nice).I agre with the productivity gains. The main thing is the incredible speed of compilationof C# compared to C++ - a few seconds for 100,000 lines of code compared to minutesin C++.

Point is of course, that a superior algorithm will often dwarf the difference between two language systems.If, (and it is a big if) C# is more productive language than C++/VB or whatever then it leaves you moretime to focus on structure and efficiency. Also of course processor power is cheap relative to people, it is frequently cheaperto buy more poke than pay a guy to recode. It is always easier to make correct code efficient, than efficient code correct.DominiConnor

someguy2,I asked for examples in which you could do something in another language which you could not do in C\C++. Not an example of something which could be done easier in a different language. Read my posts a few times before replying to them next time and maybe you will get a clue.Is Bruce Eckel some type of God? So what he says is true, and there cannot be a discussion about it? Most Java developers which I am friends with develop in notepad or a different text editor because the company they work for is to cheap to buy an IDE. So do you still believe that a Java developer using notepad can create applications faster then me using MFC? Get a clue dude!What I don't get is when people say you are always more productive in one language then another. So you are telling me that if I take 3 programmers, one a 5+ year MFC guru, another a 5+ year Java guru and the other a 5+ year VB guru and tell them they have to use .NET to create an application which they have little or no experience with they will be able to create it faster using .NET. You are full of sh*t. Developers become more productive with experience. The longer you use a language the more productive you become. This theory of C++ being slow to develop in only holds true for beginners because of the learning curve. You people have to remember these different languages were created for completely different tasks in mind. When developing applications you should keep in mind where you should use certain languages. A good project manager would know where and why a language should be used. Even though computers are becoming faster does not mean that programmers should not create the best programs possible. Only sh*ty programmers will do things like that.I am in no way saying VB, Java or .NET is sh*t because its not C\C++. Each language has advantages over the other. Stop saying you can always create applications in other languages faster then C\C++ because its simply not true and it makes you look stupid.

The real problem with productivity when using C++ is you have to spend all your time writing into newsgroups defending the productivity of the language.

Man this is getting nasty! My own comments are from having used C++ from the early days and having liked the language for most of the time (still do). Before insulting people, check out the recentstandards work to see where C++ is heading - i.e. garbage collection, properties etc.which will effectively make it quite close to languages such as managed C++ and C#.My claims of productivity are from having implemented an identical system in each of the languages: (a) C++ ATL/COM and (b) C#. It is a FACT that the C# implementation which is about 150,000 lines of code, compiles in about 5 seconds, while the ATL/COM code took about 5 minutes (yes, we were using precompiled headers).I have never personally used NOTEPAD for writing code, nor have I ever seen anybodydo that - man where do you work - I have though used VI and EMACS a lot on UNIXmachines and there is absolutely no comparison between VI and VS.NET.From a language-theoretic point of view, C++ is a disaster only surpassed by languagessuch as FORTRAN. This is THE reason that the IDE's supporting C++ is so primitive compared to C#, VB.net etc. Go read up on LR and LL parsing if this needs any moreexplanation 'dude'.Things that can be done in C# and the other 20 or so languages in .NET that CANNOTbe done in C++ include such things as reflection, which make it possible to easilywrite nice things such as interpreters and generic browsers - this is not academic -we do it in a commercial product for OTC derivatives.Where are your performance figures for C++ - go check out *real* benchmarks published by guys at ANL and the like if you want to see the truth about numericalperformance of C++.Developers who work in banks with Excel, love blaming problems on Excel - thereality is that 99% of the time, it's a dodgy DLL they wrote .... good excuse thoughin front of a trader!Finally, as much as I hate binning anything, I have to say it - MFC **IS** and always has been a pile of SHITE. There is not one technical feature that is impressive. Anybody who thinks you can build an app faster with MFC than .NETjust has never looked at .NET

someguy2,Well atleast you have a sense of humor.

jamesbattle,I hate to tell you this but MFC is actually part of .NET! It falls under C++.NET unmanaged code!