• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

What OS is standard in industry?

Joined
10/28/09
Messages
12
Points
11
As I'm learning C++ I want to start developing stand-alone apps with GUI and everything. As the title states, is there a standard OS in industry?
 
Your question is a bit too generic. If you are refering to desktops, then Andy is right. There is a wide variety of C++ developer frameworks.

The code will execute on server-side which is mostly UNIX. So, code would need to compile under a UNIX C++ compiler (e.g. gcc). Some developers may use frameworks that run on servers directly (e.g. Eclipse on UNIX) or even simple editors (e.g. vi)
 
Most GUIs do not require that kind of fine-tuning so are done in "easier" languages like C#, VB, or Java, in a Windows environment. If needed the heavy lifting will be done on a UNIX server (mostly Sun Solaris or Linux) using C++. I would not get too hung up on learning how to code GUIs in C++.
 
Windows is the dominant OS in most banks, so you will need to get to grips with Visual Studio C#/C++. You can download free versions from Microsoft's website to start learning. They come with nearly everything that you'll need as a lone developer. The Professional Editions cater more for team development.
 
Windows is the dominant OS in most banks, so you will need to get to grips with Visual Studio C#/C++. You can download free versions from Microsoft's website to start learning. They come with nearly everything that you'll need as a lone developer. The Professional Editions cater more for team development.

Generally a false statement. Banks may have quite a few developers, they are not buying hundreds of licenses just to develop code in Visual C++. Especially since the code needs to run on UNIX platforms in production anyway. So it would need to be Gnu compliant.

.NET is the only Windows based development framework, primarily front-end stuff. Mainly C# rather than C++
 
I wouldn't say you need to learn Visual Studio, but in my opinion it is the best environment to learn C++, especially since it is free for students, and the express variant is free to everyone.

Stefan raises the point about cross platform development, and in my experience >90% of code never has to cope with that. That cuts both ways, much Unix code never goes to Windows and vice versa.

Of course some code needs to work in Win32, Win64 and 5 versions of Unix, which can be challenging.

Very little code needs to be "GNU compliant" and only a vanishingly small % of developers can do that anyway.

The fact is that in most development in this domain, your job is to get it to work on the system in front of you. If it works well and soon, you are a good developer, if you delay it, or it runs slowly or crashes because you refuse to use a feature that is not "portable", your popularity will decline quickly.

Here's an example of how blind patriotism for O/S helped cause a guy to not get forwarded for a good job.

We were discussing s/w dev, and I mentioned how Windows memory management was more sophisticated than Linux. He disagreed vehemently.
That's an acceptable response, what was not acceptable was his answer to my question "in what way is Linux memory handling better ?"

He had no answer at all. Big points loss there.

If he'd have mentioned an ability to finely control which pages are most likely to be written to disk or issues with fragmentation we could have had a good discussion, but it was not to be.

I see too much of this sort of thing, especially from open source people. The difference between opinion and prejudice is evidence, and "this part of Windows I used 10 years ago and wasn't as good as the thing I have now" isn't evidence.

I'm not blind to the defects in Windows, indeed I doubt any here could cite as many as me, especially since IBM paid me a pile of money to enumerate issues in MS code.
 
Visual Studio also has GUI tools "out of the box" with Windows Forms. If you're looking for graphing tools as well (which you probably will be if you're doing financial applications), then try this: Main Page - ZedGraphWiki
 
I wouldn't say you need to learn Visual Studio, but in my opinion it is the best environment to learn C++, especially since it is free for students, and the express variant is free to everyone.

Stefan raises the point about cross platform development, and in my experience >90% of code never has to cope with that. That cuts both ways, much Unix code never goes to Windows and vice versa.

Of course some code needs to work in Win32, Win64 and 5 versions of Unix, which can be challenging.

Very little code needs to be "GNU compliant" and only a vanishingly small % of developers can do that anyway.

The fact is that in most development in this domain, your job is to get it to work on the system in front of you. If it works well and soon, you are a good developer, if you delay it, or it runs slowly or crashes because you refuse to use a feature that is not "portable", your popularity will decline quickly.

Here's an example of how blind patriotism for O/S helped cause a guy to not get forwarded for a good job.

We were discussing s/w dev, and I mentioned how Windows memory management was more sophisticated than Linux. He disagreed vehemently.
That's an acceptable response, what was not acceptable was his answer to my question "in what way is Linux memory handling better ?"

He had no answer at all. Big points loss there.

If he'd have mentioned an ability to finely control which pages are most likely to be written to disk or issues with fragmentation we could have had a good discussion, but it was not to be.

I see too much of this sort of thing, especially from open source people. The difference between opinion and prejudice is evidence, and "this part of Windows I used 10 years ago and wasn't as good as the thing I have now" isn't evidence.

I'm not blind to the defects in Windows, indeed I doubt any here could cite as many as me, especially since IBM paid me a pile of money to enumerate issues in MS code.

Of course VC++ is a good framework especially for learning. You are correct also that most of C++ and other libraries (e.g. boost) will be fine under both environments.
However the truth is that production code in banking does run primarily on UNIX (not just Linux). My response was addressing only this direction ...
 
I'm not sure why you think that the majority of production code runs on Unix ?

A large % to be sure, but not a majority. In some areas like algotrading I'd accept that position, but I read job specs as part of my job and Unix is not the primary target.

In quant work, I'd assert that > 70% of development time is on Windows boxes, possibly more.

But...
That's not the right question.
The right question is to ask which skill offers the best return on an investment of your time and skills ?

The best paid entry level roles we've had this year have been under Unix, first year comp a good multiple of the average. But you have to be exceptionally good at it to a level that almost no one achieves.

Conversely, examining the questions people get at interview when going for quant developer roles, I find that few are operating system specific, deep grasp of programming is more important.

I've been toying with building a standard set test for entry level QDs to prove their worth. I keep hitting the problem that it depresses me, so I put it off.

When someone looks blank at the idea of a hash table, or a blackboard, it nails this coffin a bit more. Monte Carlo is not the solution to every problem in numerical analysis, and it would be nice of Sobol wasn't a new word to people so often.
 
Back
Top