I thought C was THE language of choice back then. Now it's anything goes. Personally I like C# and my absolute favorite is Turing. Too bad Turing was never developed for software programming and it remained as a pedagogy language.
Having one language for all is neat, to avoid creating Frankensystems. If parts are proprietary or 3rd party dependent, only matter of time before it breaks. Apart from simplification, you can be much more productive choosing right tools for the job, involving more platforms and languages. Again, if you aren't consistent, nothing but fixing that really matters anyway. Kubernetes and micro services are interesting to scale up operations.
Most production code at hedge funds and especially high frequency trading firms is not based on an interpreted language. Front and back ends are either purchased platforms, or proprietary in-house applications that either rely on a web UI or C#/WPF for front-ends and C++/Java/C# for back-ends. Interpreted languages such as Python are generally used for research/prototyping. But for any front-end/backend work Python is hardly to be seen. One thing I noticed when I worked in the US was that the larger the organization the more antiquated and complex their IT frameworks and implementation, much more so than in Europe/Asia. Of course that makes sense to a large degree given that a lot of large banks/hedge funds acquired countless other banks and firms and had to merge IT networks over and over. But smaller to midsized funds (sub 2bln USD) certainly do not use interpreted languages for anything other than prototyping as part of their research process. At least the huge majority.
Python has everything you need for trading.I run intraday scans in python works fine for 1 minute scans
I have to disagree with you on that one. I've interviewed a lot of people from all sorts of places and can formulate an opinion about what is "the state of the art" in the industry. Granted, my view is framed by the PM perspective, so I don't really know what's happening in the back office, for example. Firm-side and broker-side software is probably be very different (stable, takes ages to add a feature etc) and from a PM perspective these are "exogenous" parts of the problem, just like the exchange connectivity. First, forget about HFT shops, as they are their own beast (this said, I have accidentally done a stint for an HFT firm and people there roll a LOT of python for non-trading path stuff like reporting). I am talking about places that are doing medium frequency stuff and/or semi-discretionary trading. Also, let's restrict ourselves to large multi-manager platforms and mid-size funds because that's what I've seen. Second, let's define "production code". How about "a path of software components that participates in live trading or managing live risk" at the level of alpha unit? Along that path is historical data analysis and model fitting (i.e. recurrent pre-trade analysis) pre-trade/SOD environment generation long-term target generation actual order generation and submission execution/position allocation risk reporting/trade reconciliation, PnL attribution and other misc stuff. Most of the people I've spoken to use various forms of interpreted languages for most of these steps, with an important exception of step 4. It usually would be the same language that they use for research since it allows for very quick idea-to-trade time. PS. "font end", "UI"? Have you ever seen any alpha-generating team spend more than a cursory amount of work on the user interface?
I'm not sure what kind of Java you're using but I've never experienced a benchmark that wasnt competitive with other JIT languages. It's speed (when properly warmed up and optimized) is comparable to C++ compiled with GCC. The benchmark game shows some of these but some of the multi-threaded tests are questionable. Old Java wasn't great, but if you've programmed Java any time more recent than 1997 the benchmarks for Oracle JVM Java are solid. There is a lot of high performance code running on Java. It's still one of the highest demand languages. I've personally written very highly optimized Java backends that are still being used today. No idea. I started in Excel when I was doing my quantitative finance and modeling courses (options, futures, swaps, etc were all priced in Excel). I wasn't around back then but judging by the interviews in Schwager's books there wasn't much computational finance going on. I was a little hard on Python up there. I still like Python. It's replacing FORTRAN (now Fortran...since 1990) as the language of scientific programming. LAPACK is still the be-all-end-all of high performance computational linear algebra - it was written in Fortran 90. When I left university they were still teaching Fortran to engineering students though every mathematics class had been converted to MATLAB. At the end of the day you really don't need much unless you're doing some really complicated work.
Came in to say that. I've been writing c# for years so it was natural for me, and as yous said there's a ton of documentation out there that's in c#. I occasionally have to write python, which drives me nuts, but it's a good skill to have. R is good as well for the times I've bumped into machine learning.
Ha, with all your "restrictions and focus" on a very specific niche you might well be right. But as I got an impression we are generally talking about financial firms that are engaging in trading financial assets I took the general view. I have worked at 5 large international investment banks in the capacity of flow trader, quant trader, and prop trader in both fixed income and equities, and at an undisclosed hedge fund, and have quite a number of close friends who work at several hft firms and hedge funds. Nowhere are interpreted languages used for any production and mission critical code that goes into the apps used to run the back, middle, or front ends. We should not confuse use cases where, for example, reports are generated and some guy in product control or so applies VBA macros or other Python code to customize things for specific traders or risk people. But that is an entirely different beast from stable production code that is audited and takes months/years to move into a stable production environment. I would be curious if you could name a single product on the front-end side that is available for purchase for production environments that is written in Python or VBA. If at all then it is individual apps that specific people use to make their lives easier. But certainly not production code on which clients execute millions of, for example, algo orders or risk management values/stresses trading books on a firm-wide and often global basis. Most items on your list would only apply to interpreted language usage in very small firms/teams that either can't afford expensive proprietary software or do not have the budget for large IT teams. Such smaller firms might "stitch" things together here and there but I highly doubt this qualifies as production and mission critical code that a seasoned senior management and risk management division would ever sign off on. Heck, in most firms it takes weeks/months to just get a hard disk purchase approved and any hardware/software that is implemented in production environment goes though multiple layers of rigorous vetting, testing, and approvals before it is employed. I would claim that a trader at any mid- to large sized hedge fund would immediately get fired if it was found that he himself "altered" the order submission process by applying some sort of hack via interpreted languages to tailor to his/her preferences. Your last statement definitely is a reflection of your own limited view of things at your firm or the few people you spoke to. Applications/software in research/development are in almost all cases strictly delineated from production code. R or Python are hardly EVER used in any production trading environment at any reputable firm, whether bank, hedge fund, or hft firm. Please name a few firms that programmed their OMS or order routing/execution in Python, I would love to learn and am happy to stand corrected. I am pretty sure you won't find all that many. Or perhaps a few firms that injected some interpreted language hacks into the pipeline of data sourcing (Blomberg pipe/Reuters RMDS -> backend apps in production). Other than at the consumer end in research/development nowhere in this pipeline are interpreted languages to be found. Re frontends, yes, most firms spend a fortune on developers and technology to get the front ends right as well. All the technology is wasted and money lost when traders or support staff find a hard time to enter their trades and make adjustments on agreed trades with counter parties, for example. None of those front ends are written in interpreted languages either. Sle, I do not mean to differ with you constantly on issues but it appears several times now that we differed and when laid out my arguments you restricted the universe to a few niche cases. Your points might all be valid in small offices where there might be budget constraints but at most reputable banks, hedge funds, and hft firms and especially on the buy side where the issue of fiduciary duty is more than anywhere else adhered to, interpreted language hacks are just not acceptable business practice. (and yes, VBA and other script code and interpreted languages are nothing but an unstable hack and should only be utilized when mistakes or errors are acceptable)