I think Python is as good as any language to start with. Each language has its own quirks. I personally do not use Python, but have used it before and it is fine. Plus, if the OP learns Python, he can transfer that skill set to something like Quantopian. (Or if he chooses C#, QuantConnect).
What you learn in Excel will be transferable to any other language, but a language like Python will not be immediately transferable to Excel. This is because Excel is based on more mathematical constructs (functional declarations / formulas), while python is like giving orders to the computer exactly how to do stuff (imperative programming). Don't worry, you may need some time to learn the distinction, but it's there and it's real. In a way, building with Excel is like playing with lego. You see connections and build prototypes, that may help you later, and it's more fun. Coding in a real language though, requires that you know more exactly how to build something and also learn alot on how to use that language and libraries. Excel's got an undeserved bad reputation among programmers. It's usually accurate enough and you can weed out quirks and bugs, just like any other language and framework. Fixing fundamental flaws is really part of programming, since your tools are never perfect to begin with. What it'll give you though, is more intimacy with the numbers and formulas, which is good in the beginning. It depend on your temperament, capability to learn and what'll work for YOU. In the long run, Python will make you able to program most anything you need, while Excel may make you more aware of what you actually need faster. So you may learn faster and accomplish more in Excel at first, and this might be good for you in the short-term, both to program and to specify your thoughts into instructions for the computer. Using something like Python is like driving a car instead of a bicycle, you'll need to learn more, but can get more done later. However, there are other languages too. C# is not too bad and can be used in Ninjatrader, where you also see charts directly. So it's not really either-or, but you can do both, which of course may take more time and work than you originally planned for. In fact, the options for programmers are often so overwhelming, it's hard to get projects properly designed and done, until you know exactly what you need and how best to accomplish it using existing tools and libraries, or writing your own from scratch. I know we all want to rush things, and it's natural, but these things takes time. What I said about automatons upping Murphys Law is no joke. It'll take ALL instances of signals, even those a human would pass on immediately. Not sure how you've managed to backtest everything already if you aren't a programmer, and there are all sorts of biases that creep in, ie. from your own selections or surviving instruments.
Additionally to what @Simples says, I love prototyping in Excel (VBA). Its cellular structure reduces the coding burden, so does its built-in "GUI." But its 2-D structure can also get in the way when vast changes need to be made in the future. And it's relatively slow compared to most languages. The built-in Solver is also nice. You can quickly test things before spending a lot of time writing an almost full-blown program. I will be porting my algo over to a fast language (probably Golang) eventually, but I upgraded to a fast computer to tie me over until then. My excel, with the faster computer, is actually fast enough to do the job. Now I can learn Golang at a slower pace.
Everyone gives up within a month if not a week. to go from zero, learning a language ,to writing an automated trading system. maybe someone could give an o/u
My first attempt at backtesting momentum in ruby was pretty crappy. Have since improved all aspects in golang and am productive (ie. got essentials like indata and main loop nailed). Of course I dont get charts and heatmaps like in NT but these things are deceiving anyway. Just need to avoid making too much of libraries. Like early days of OOP and C++ many people focus on making fancy libraries instead of more direct programs that solve stuff. Though golang will help with structure too. Already got a fast comp with 64 Gb memory and is good to avoid early optimization. Like C# (pure C#, not NT structures), golang is usually fast enough to do anything I throw at it per default and dont need to optimize so heavily as with ruby.
You are right. I'm one of that person who gave up many times at the beginning, but in the end I made it. My background is finance, but with hard work and many many sleepless nights, I managed to grasp it. Now I'm quite efficient in low languages like c/c++ or higher lang like Python. What I would recommend to someone new, is to start with Java. It is in the middle. One of the most important thing is the debugging environment. Java environment is very easy to debug. Regarding the quantopian stealing your ideas, this can be avoided quite easy I think. From what I know their engine is open source in Github, so you can take it and use it offline on your own server without relying on any of their services. Personally I decided to build everything from zero. The good part: learn how to code and flexibility. The bad part: it took a lot of time. Trader Nomad, I recommend you to learn how to code. Hire someone to teach you and follow along the lines. After you will get the OOP concepts, you will see how easy is to implement different problems from the real world. You will broaden a huge new horizon if you know how to program + finance.
I have used IB's DDE and ActiveX sheet for a long time before, as I stated before, once you update your API or even TWS in certain cases, it breaks and debugging ActiveX is a pain. You typically customize the sheets for your usage and imagine doing all of that again once the sheets are updated and radically changed (has happened before). The API itself is backwards compatible so if you're using the native Java version of a 3rd party wrapper like IbPy, it will still work. I only switched from the Excel versions because of the regularly appearing problems. I haven't even had a single problem appear overnight with IbPy, it works just like yesterday. Excel is definitely easier and faster than any real programming language but at what cost? For my trading, I need to be certain that things have been transmitted and everything is synchronized. You really can't be sure with Excel as it's very hard to handle errors. It's up for the OP to decide what he wants but for me, I wish I wouldn't have wasted time playing with the Excel/IBAPI mess.
Exactly....no way that IB will support it....that's the risk. Your other option is www.quantopian.com BTW: What's all of the hoopla over Python for developing trading systems ? What's it's advantage over traditional languages ?