Page 1 of 1

What language then...i am confused

Posted: Fri Nov 12, 2004 6:04 pm
by Martina
Hello all,
What language then...i am more confused after reading the posts :roll:
I have been working with TS Easy Language so is the time for me to learn more serious language...i am looking for one which i can use the most/would talk to most platforms and i could build on the knowledge in the future as well. What language is the VeriTrader written in?

Posted: Fri Nov 12, 2004 7:08 pm
by d-g
VeriTrader will use a simple scripting language that you could learn from the ground up in little time. More details will be available upon release, I am sure a number of the beta testers will comment, once the official release is made.

Re: What language then...i am confused

Posted: Fri Nov 12, 2004 7:24 pm
by Roscoe
Martina wrote:What language then...i am more confused after reading the posts :roll:
That really is the question! If you just want something a little more than point and click then you are really just choosing software, however if you are really serious about powerful applications and you are willing to work at it then take the time to evaluate each language contender very carefully.

I faced the same question a few years ago – the limitations of Easy Language were fast becoming evident and I had to make a decision. I chose C++ for a few reasons, but that is not to say that my choice would suit you. IMHO you need to start by determining exactly what it is that you want to achieve – I wanted a language that had the following features: powerful - virtually no limitations beyond logical constraints; able to interface easily with other applications; and a large user-base with well-supported training (books, courses, web forums, etc). For me C++ met those requirements.

I rejected Easy Language due to TS limitations (e.g. systems problems, messy or non-existent portfolio or position-sizing options); I originally planned to use VB, however I rejected it because it was just plain messy, or at least that’s how it looked/looks to me; and I rejected things like Java and C#, Net, etc because they seemed much more slanted towards web-based applications whereas I was looking for just plain vanilla grunt for extensive testing.

Whatever you choose please take your time as you will be investing a lot of time into learning how to use your selected language.

Posted: Sat Nov 13, 2004 2:35 am
by Bernd


Posted: Sat Nov 13, 2004 1:48 pm
by ksberg
Bernd, nice and concise rationale, and thanks for sharing the fact that things change. The evolution is something I can relate to. I found that each decision to switch it has been more than a "port", since my trading platform ideas evolved as well. Usually the switch enabled me to re-think the approach, and sometimes the change in language itself forced a re-think (e.g. coming from Smalltalk to Java). And sometimes it takes learning something before deciding what path to enable next. Anyway, here's my rationale and evolution ...

Why did I use C++?
- I knew the language.
- I wanted to be able to use 3rd party libraries.
- It seemed like a good thing to use at the time

Why did I switch to Smalltalk?
- Better support for abstractions
- I work 10x faster using Smalltalk than using C++
- I was initially able to gain better leverage than using 3rd party libraries

Why did I switch it to Java?
- The Smalltalk vendor disappeared
- Java is ubiquitous and free
- There are many high quality libraries freely available
- I work faster in Java than C++

Have I considered using any other languages?
- Yes, C#, Groovy, D and K
- The cost of porting is very high and outweighs the benefits in every case
- I want to ensure multiple vendor, multiple library and multiple platform support
- I want to ensure my choice is viable well into the future

What langauges would I consider if I were starting from scratch?
- Java and C#, in that order

What do I see as trade-offs and preferences?

- Java is supported everywhere (American Express card up to Mainframes)
- C# CLR (common language runtime) is supported on Windows, Mono and GnuDotNet are up and coming
- I have many viable options for JVMs (Java virtual machine ... Sun, IBM, BEA, Kava, etc)
- Many vendors, many years contribute to JVM tuning, CLR only has MS and other CLRs aren't tuned

Development Environment
- Personally favor Java IDE (Eclipse vs Visual Studio), mainly due to refactoring support
- Eclipse round-turns are faster than Visual Studio (compile/edit/link/debug)
- Eclipse is completely extensible and configurable
- Eclipse integrates with standard OSS tools, like ANT (hyper-flexible build environment)
- Visual Studio doesn't have ANT equivalent (Microsoft will support their own offering in late 2005)
- Most Eclipse extensions are open source, and you can also build your own
- Eclipse is actually flexible enough to become your application (a Smalltalk paradigm)

- C# (.NET) has better widget support for Windows
- C# has good commercial widget support (e.g. charts)
- C# widgets run on Windows, Java widgets run on Win/Mac/Linux
- There is wide selection of commercial and free Java libraries
- Equivalent C# libraries cost more than Java libraries, and there is often no open source equivalent
- With C# libraries I have spent more and gotten less than equivalent Java libraries
- Networking and server support is far superior in Java (e.g. JINI process farms, JMS, EJBs) with no or few .NET equivalents
- Java libraries are more likely to support Patterns (Gamma et al), which aid modeling and can lower complexity
- Server design patterns are not well supported in C#/.NET. In fact, many are hard to achieve

I find it interesting to look back at my own decisions and see how current rationale evolved. In particular, I felt really burned by the Smalltalk decision, and was left high and dry when vendor and community dried up. As a result, I have a very high bias toward ensuring language, vendors, community and libraries remain viable well into the future. I can see that I'm also influenced by the type of commercial enterprise applications that I build, which may not be shared by other developers.

All this is a lot to take in for someone just starting down the programming path. I'd say that Java and C# are both very viable options, and that C# has the edge for creating Windows desktop applications. If you desire something beyond the Windows desktop, C# very quickly becomes a hindrance and Java shines.



ps. I find it difficult to recommend C++ to anyone starting down the programming path. You will spend a significant portion of your time housekeeping and learning how not to accidentally cut yourself (or worse).

Posted: Fri Nov 19, 2004 11:52 pm
by zeta
Since I've just completed the first phase of my simulation engine in C# (using VS.NET 2003), thought I'd add my 2 cents - Frankly, the logic of most types of simulators can be expressed in most languages without much trouble - the question is to find a tool that doesn't get in your way and provides a good debugger. On that note, I must add that I definitely agree with Kevin & Bernd - C# or Java are going to be much easier to use than C++, especially for someone who is just learning to program. I chose C# for two main reasons:

1. I was familiar with the VS.NET debugger and wanted to largely stick with that as opposed to picking and understanding a new tool.
2. C# makes it very easy to design Windows based programs, while also making it not so difficult to work with Excel (although in all honesty, I'm still figuring that one out :-)

However, the programming language is just one part of the equation - I found the design to be the hardest part . When you design your simulator, you can't really imagine all the purposes you will end up using it for - thus you have to design something that you can go back to and extend without it becoming very messy. This however, is not something that a "XYZ programming language in 21 days" book can teach you - I think it largely comes with experience.

Whichever language you choose, don't underestimate the difficulty of designing a custom platform - it really is a nontrivial piece of code. You'll really enjoy the process if you like programming, but otherwise your motivation will take many hits during the process.

p.s. Kevin: very interesting to read your reasons for choosing Java. Must check out Eclipse sometime.

Trading design and evolution

Posted: Sat Nov 20, 2004 11:04 am
by ksberg
Shiney, congrats on the milestone.

Wow. I think one could write volumes on evolution and design, and most of it is independent of computer language. One sign of a good design is how it supports evolution. Bernd's point is that you should expect a trading platform to evolve, but how do you plan for evolution? Unfortunately, design is at least one part experience, one part engineering, and one part black art. There is magic in knowing what is "just enough" and not over-engineering a solution so that you can do almost anything but it takes a lot of work just to do something simple. I'll leave the discussion of software design and engineering to other forums. Some pertinent topics include: model-view-controller, patterns, re-factoring, and even agile methods. Google is your friend.

From a trading platform perspective, I think there are some basic "inflection points" where things can become challenging depending on the initial design. Here are some off the top of my head ...

1) Market price series data formats
- Addition or change of vendor (CSI, MetaStock, etc)
- New kinds of trading data (stocks, futures, forex, options)

2) Formula
- Easily composing arbitrary functions (e.g. MovingAverage(TrueRange, 10))
- Applying deeply nested or complex formulas (e.g. Elhers)
- Integrating or leveraging external formulas (e.g. R-Stat, Excel)
- Easily extensible reporting statistics (e.g. Profit factor, MAR, Shape, K-Ratio, Sortino, etc)

3) Strategy
- Supporting different order types (GTC/DAY, market, limit, stop, MOC, OCO, etc)
- Using more than one market in a strategy (e.g. gold and bonds)
- Using other kind of data in a strategy (non price-series, call/put ratios, etc)
- Using multiple timeframes in one strategy (e.g. 5, 15, 30 minutes)
- Support for scale-in, scale-out (multiple units and trading decision points)

4) Portfolio
- Trading multiple markets in parallel (vs. assembled post-run results)
- Enabling decisions based on positions held in other markets
* Sizing a trade, sizing a position
* Taking or blocking signals (e.g. correlation rules)
- Cross currency portfolios (one portfolio traded in multiple currencies)

5) Optimization
- Expressing arbitrary ranges for arbitrary inputs
- Iterating over arbitrary input ranges and types
- In-place optimization (i.e. recursive trading engine)

6) Real-time
- Switching from end-of-day simulation to real-time
- Support for placing, routing and tracking orders (coordination between internal signal and external orders)
- Handling discrepancies between actual and planned outcomes
- Handling outages vs. mechanical signals vs. held positions
* Signal/Feed down (reconnect, resync system and decision points)
* Broker routing down (ditto)
* Internet down (ditto)
* Power failure (vs distributed systems)

Why do I call these "inflection points"? If they had not been considered as part of the initial platform design, there is often a design change to enable the functionality, implying a major headache or re-write associated with each topic. Not every trading engine needs to implement all the above (we'd never get anywhere!), but I put them out for consideration.



BTW: There are some nice libs for people wanting to using Excel from Java: I started with JIntegra and recently switched to POI. The latter is an open source library that reads and writes native Excel (*.xls) files. I know other people using SWIG (simplified wrapper interface generator), which is a great tool for creating second-language bridges into existing C++ libraries. I've also used FormulaOne on commercial projects (a tad pricy). I chose POI because it is an OSS library can be used on any platform, and does not require Excel to be installed (i.e. it even works on Linux or Solaris).

The POI folk were nice enough to advertise a comprehensive list of Java/Excel options.

Posted: Sun Nov 21, 2004 1:58 pm
by zeta
Some very good points there Kevin - I used your list to do a quick run through against my program 8)

Planning for evolution is probably an oxymoron... I guess at one point, we as programmers have to decide that one can't generalize any more without encountering significant costs (time or otherwise). This is one of the hardest decisions to make. As I would imply from pt. 1 in Kevin's post, even a simple concept such a TimeSeries can have a number of issues, for which there are no straight answers.

However, I believe that it usually is a very rewarding exercise to think about your system in programming terms. I must admit to being surprised by a number of nuances I discovered in my own strategies during the programming process.

Posted: Sun Nov 21, 2004 8:51 pm
by ksberg
shinyhappy wrote:... even a simple concept such a TimeSeries can have a number of issues, for which there are no straight answers.
You're spot on. One time-series issue that took a bit of re-work for me was supporting intermixed tick and time series data. Tick data challenges the assumption that time is equally spaced, and tick data may also be time stamped differently than time data, depending on vendor (time on tick data usually represents the last received tick, but time series data can be marked before or after completion of the bar).

Of course, the points above aren't necessarily independent either. In my example, I wanted to add tick-based strategies, which forced a re-think about my normalized data format and data adapters. The tick data change also effected multiple market coordination in a portfolio and market-on-close order handling. I think you're right about balance: there's only so much one can plan in advance and the rest you gain from actually travelling down the path.



Re: What language then...i am confused

Posted: Wed Dec 01, 2004 4:42 pm
by msalese
Martina wrote:Hello all,
What language then...i am more confused after reading the posts :roll:
I have been working with TS Easy Language so is the time for me to learn more serious language...i am looking for one which i can use the most/would talk to most platforms and i could build on the knowledge in the future as well. What language is the VeriTrader written in?
Hello Martina,
look at matlab,it's simple to learn
perhaps is more expensive, but exist a student version.

Posted: Sun Dec 26, 2004 9:48 am
by future_liffe

If you ask me, either C or C++ will be a very good option for you. Though these two languages are NOT easy, they have good free tutorials on the web and could be implemented not only in Trading Platform but for any software design/development purpose.

Feel free to ping me on Yahoo or MSN if you need more info.

Posted: Mon Dec 27, 2004 7:09 pm
by BigBang
I'm currently programming my system in Ruby, an elegant objected oriented language. It integrates easily and efficiently with C, so I use C to load the market data into memory and fetch quotes.

Ruby has the advantages of being free and running on almost any platform and it is very powerful. C is about as lean as you can get. I experimented with Perl, but it had problems with handling the huge chunks of memory I needed for the market data.

to add to the discussion

Posted: Tue Jan 04, 2005 2:08 pm
by davidgareau
Hello, my name is david and I'm wannabe...

Hi, I programmed some in Java back in college, and have read intro books on it. I always wanted to get better, but never needed to write any programs... until now. First Metastock, then Tradestation 2000i / 8.0 now I have finally found a reason to learn real programming.

2 questions:

1. Do you guys/girls write your systems only in (fill in favorite language) and then use platforms like Metastock or Tradestation to show the charts and to automate trading, or do your programs actually write the charts and automate the systems. How is this accomplished, the second option, with different brokers, how do you integrate the program you wrote, into your brokerage account? Or are most of you just using this for testing purposes? (wow, that's more like 10 questions, sorry.)

2. Java or C++
I already know some Java, and the learning will go faster, but in my searching online, I have seen only (and very few) books on C++ for systems trading. (any other websites you could recommend for programming your own systems) I have seen a lot more jobs for C++ Systems Programmers than java, most Java Jobs were geared towards programming brokerage's web-based platforms. Although a job is not my goal, these things make me think that Java, and the community of support behind it, might be not there for trading? I think C++ more, simply because I've worked on Unix systems and everyone there (except me) knew C++. Are the benefits of C++ for traders worth say the 6 months more of study I will have to do in it to catch up to my java level?


Posted: Wed Jan 05, 2005 12:26 am
by shakyamuni
Hi David,

You might like to read the above postings by Bernd, ksberg, ShinyHappy, and Roscoe.

Posted: Wed Jan 05, 2005 7:01 am
by davidgareau
I did read the posts, and I completely agree that there are some interesting feuds about it. So, let me be more precise.

If I learn C++ will there be a
1. MUCH bigger support community
2. MANY more libraries and pre-exisitng TRADING-specific code available.
3. MANY more jobs available, in case it ever comes to that end. Always have a safety net.
4. Many more books available to further my systems Trading Programming?

Than if I learn more Java?

Also, the question remains are most of you guys/girls doing programming in a "real" language, just for the sytems itself and then testing it in a 3rd party software like TS or Metastock. Or are you creating your own software for showing charts and all?