Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
that, along with inherent parallelism, are all good things.
I'm currently in late stages of developing a trading app (which is why this thread resonated with me). My pick was Java. Based on what I know having gone through this exercise, I'd never pick a non-OO language: behavior management may get quite tricky and it's my preference to solve that by manipulating objects. Based on the little that I know about Fortran, Fortran would be totally out of question. Again - that's me, to each his own.
Can you help answer these questions from other members on NexusFi?
Firstly, I want to say the good things about Python so you know I'm not completely biased. I also want to emphasize that you notice that I've commented on both sides of the fence for every language I've discussed, and this is true to my principle that there's no best language, only the best implementation - it's up to you to take advantage of the best features of each language and what you're most familiar with.
1. It's cross-OS-compatible, lightweight and comes prepackaged with most UNIX-based OSes, making it a good scripting language.
2. It has a very large number of libraries that have been made really easy to install with setuptools.
3. It works very well as glue code between different languages. Definitely can't say the same of C#.
4. Python supporters generally will argue that it's fast too since you can integrate assembly code and C (Cython).
However,
1. It's dynamically-typed, which makes it a serious piece of crap and it suffers all of those symptoms: Static analysis and refactoring is crap (pylint seriously?). Python optimization presents you the illusion of choice: you mostly reduce the call overhead or assimilate C/assembly, both of which don't really solve the problem because the Python interpreter is much more opaque than, say, the .NET CLR with the help of Reflector.
2. It's dynamically-typed.
3. It has very poor support for multithreading.
4. It's bad for managing a large project.
5. It suffers from most of the bad things about open source but few of the good things about it: the adoption rate for Python 3.x has been slow so you have to deal with two different directions. Open source guys believe in a very small set of orthogonal features and modularity, leaving it to the community to develop the little bits of functionality that you might commonly use. My experience has been that a project that might take referencing 0 libraries in MATLAB (since it's a global namespace), maybe 3-4 .NET framework libraries in C#, often requires you use like 15 third-party libraries in Python (for lack of the right data structures, parallelism etc.) most of which have very inconsistent naming convention and crappy documentation or development effort. Generally, the argument for going with Python is that it can replace the statistical functionality of R/MATLAB, but honestly, the statistical packages in Python are poorly-documented, a very small subset of that available in R/MATLAB, and known at some points in time to have been inaccurate. I've mentioned this elsewhere before:
6. It's dynamically-typed.
I'd say three good things going for F# are that it's on top of the CLR, which makes it convenient (although in a trading environment, this advantage is partly offset by the fact that there's a lack of F# wrappers or native APIs), and it's based off OCaml - which makes the syntax clean for team communication, and it has built-in concurrency.
Again, these are great features but there's rarely a common line of comparison between languages; it's up to the user to find an application that best takes advantage of these features.
I would expect the Fortran compiler to be used for legacy support. I think many financial applications were written in Fortran and now only maintained.
Last I have seen, most colleges are requiring basic programming with C++, C#, or Java. I haven't heard of even Pascal or Fortran listed as a core requirement.
I don't know much about F#, I even have some concerns about what I know about complied C#. My understanding is it goes into an intermediate language that can be easily de-compiled. As a coder, this concerns me and I don't fully understand what to do to protect my code. Not sure I need to do so yet, but know this is one more step before I can distribute anything I don't want to release as Public Domain. I know there are Obfuscation routines, but don't know much about how well they protect your code.
From my perspective, the language is a little immaterial. I have "programmed" in all languages (other than F#, that I know of). This is very similar to English, German, Spanish, French, etc. You can still convey what you need to in these languages, there is just different "words" and syntax to comply with the languages.
Same as in programming languages. They main difference is some languages FORCE certain structures into your code while others do not. This is good and bad. It is good that it means your code is more predictable in what it will do as you are less likely to code something that performs differently than intended. It is bad in the fact that it likely takes more time and effort to build the structure around what it is you wish to do. For example, C allows for the use of "Pointers" in your code. They can lead to crashes and coding errors as the software doesn't know what it actual points to, and heaven forbid, your point is NULL and you write something to it. This tends to point to system space or protected. But sometimes with pointers, I could reduce the complexity of my code significantly, but it is more difficult to support later.
I see Jane Street brought up very often in programming language discussions among traders. It's true that they're one of the largest prop firms but it's still a single sample. I know several guys who were at Jane Street, their office is in the same building as a law firm that we used (makes me wonder how they handled the Hurricane Sandy flood now that I think about it) and my understanding is that they do fairly vanilla trading for the intellectual image that they exude, and shouldn't be used as the basis of some argument that functional programming is any better or worse for trading.
Now, they can say all the good things about OCaml, but they're glossing over the business decisions from the position they were in: they were a small group of ex-SIG partners, all experienced and familiar with OCaml, and they had to start their own firm from scratch. And this was 2000, when OCaml was at its highest peak. Computer architecture and market structure has gone through tremendous changes between 2000 and 2013. 13 year later, they have all that legacy code in OCaml, so they don't have much of a choice besides to argue that they're using the best language in the world.
I guess that your message was not specifically addressed to me, but I want to make clear that I was not arguing or promoting anything.
Coming back to the original question, I would say that the first step, before creating something from scratch, is to use the language provided within an existing platform. As major ones give access to C++ or C#, the possibilities are nearly unlimited.
If, for some reasons, one wants to build something from scratch, the language really depends on the timeframe, the need to connect to real-time data feed or not, the need to connect to broker (versus manual entry), one's coding comfort zone, the nature of analysis performed, etc. Everything is possible as long as it suits the needs. If my memory is correct, Ernst P. Chan uses Matlab and Excel.
To answer the original poster... Unless he's doing HFT, I'm also going to suggest he determine which trading platform he would prefer to automate his system(s): Sierra Chart (C++), Multi-Charts (C#), or NinjaTrader (C#). My personal preference is NinjaTrader for developer and broker support.
But back to the debate...
I would love Julia to get more traction and developer contributions. A quick description from the site: "Julia is a high-level, high-performance dynamic programming language for technical computing, with syntax that is familiar to users of other technical computing environments [MATLAB]. It provides a sophisticated compiler, distributed parallel execution, numerical accuracy, and an extensive mathematical function library. The library, largely written in Julia itself, also integrates mature, best-of-breed C and Fortran libraries for linear algebra, random number generation, signal processing, and string processing. "
Its got a ton of potential and a bright future.
EDIT: Recently Julia and Python integration has been added. More info is available here and here.
