Trading System Languages Likes and Dislikes

Questions and discussion of Trading Blox and other platforms for non Trading Blox customers. Trading Blox customers should use the Trading Blox Support forum.

VeriTrader's language should be most like?

TradeStation EasyLanguage
11
21%
MetaStock's Language
3
6%
Trading Recipes Language
5
9%
WealthScript
8
15%
AmiBroker's Language
3
6%
None of the Above, They All Stink
23
43%
 
Total votes: 53

Forum Mgmnt
Roundtable Knight
Roundtable Knight
Posts: 1842
Joined: Tue Apr 15, 2003 11:02 am
Contact:

Trading System Languages Likes and Dislikes

Post by Forum Mgmnt » Fri Jan 16, 2004 12:01 pm

We're working on the next version of VeriTrader which will be programmable.

I wanted to solicit the advice of the membership at large as we work on the trading system language itself.

What do you like about the trading system specific languages you use?

What don't you like?

Any suggestions as we work on the language for VeriTrader 2.0?

I'm not so much interested in syntax issues as I am in the way that the language interacts with trading and trading concepts, but if you have a particular syntax-related pet-peeve, I suppose we should know about that too.

Thanks in advance,

c.f.

P.S. If you answer none of the above in the poll, please post your two or three most hated "features".
Last edited by Forum Mgmnt on Fri Jan 16, 2004 4:07 pm, edited 1 time in total.

Jason Czech
Roundtable Fellow
Roundtable Fellow
Posts: 68
Joined: Fri May 16, 2003 8:28 am
Location: Atlanta, GA

Post by Jason Czech » Fri Jan 16, 2004 2:16 pm

I vote Wealth Script, but I can only compare it to MetaStock as I haven't used any of the others. The one irritating syntax feature though is the fact that you must enclose each statement block with a "begin" and "end".

I'd think that most any scripting language syntax would be ok, what is most important is having a complete, and well documented, function library.

It would be nice if the language would alert the scripter to forward-looking code.

When testing a trading system against stock lists which include inactive issues, WL does not close out trades when the last bar in the series has been reached.

WL is not very good at allowing the scripter to communicate between symbols in a portfolio simulation run. For example, I wanted a way to create position sizes based on closed equity, but wealth script doesn't have any way to obtain this figure, or any other global figure other than total equity. I guess that maximum flexibility is the key.

I wish I'd known about VT prior to purchasing WLD :)

cyphrograph
Senior Member
Senior Member
Posts: 39
Joined: Thu Oct 16, 2003 11:38 am

Post by cyphrograph » Fri Jan 16, 2004 2:17 pm

Ami Pro? What is it?

Bondtrader
Roundtable Knight
Roundtable Knight
Posts: 101
Joined: Mon Apr 28, 2003 11:07 am
Location: Zimbabwe

Post by Bondtrader » Fri Jan 16, 2004 3:23 pm

I only started to appreciate the features of one trading platform's system definition method, when I gained access to other platforms and saw how they did things differently.

The usual suspects will list the usual advantages of Trading Recipes, so I won't repeat them here. Instead, I will provide a list of Good Things in Tradestation which are absent in Trading Recipes:
  1. Source code is provided for all "builtin" functions. This turns out to be invaluable when you're getting unexpected results and start digging into the code to find out why. TR users who have tried to use "ATR[15]" to get the 15-day average true range will know exactly what I mean. And God forbid you should ever try to use TR's linear regression or trendline functions: they're not documented and you can't see their source.
  2. "Change my position from flat to long" and "Change my position from short to long" are not required to be two different pieces of code (located on two different "pages") in Tradestation. The keyword BUY accomplishes either, and/or both.
  3. Blocks of code are supported in Tradestation; you can say "if today's close is less than yesterday's close, execute the following twelve statements" (i.e. begin .. end). TR doesn't have blocks, you use JUMP statements instead.
  4. Tradestation knows that sometimes, programs want to deal with integers, and it provides a host of builtin functions for integers. TR only knows about floats and booleans. You can't tell TR to round something to the nearest integer, for example. Nor can you calculate a remainder.
  5. Tradestation include several of the more common loop-iterator constructs. It'll let you code a for-loop and a while-loop. TR won't.
  6. Source code can be constructed hierarchically in Tradestation using include statements. TR has no such thing.
  7. Tradestation functions have argument lists, just like a real programming language. TR "GOSUBs" read and write global variables.
  8. Tradestation code can write to disk files (or to the printer) while running, TR code only affects the GRID.
  9. By separating "strategies" from "user functions", Tradestation allows you to call these functions in several different systems without having to retype the function's source code every time. TR doesn't access a function library (except the builtin functions), so all usercode must be retyped in all systems that use it.
  10. Tradestation makes it easy to refer to the open,high,low,close of other markets using Data2 and Data3. This is cumbersome at best in TR.
I could go on for a lot longer, but will let others pipe up. Somehow I expect that maybe J.B. might reply too.

Forum Mgmnt
Roundtable Knight
Roundtable Knight
Posts: 1842
Joined: Tue Apr 15, 2003 11:02 am
Contact:

Post by Forum Mgmnt » Fri Jan 16, 2004 4:10 pm

Ami Pro? What is it?
Well, I guess I did get old when I turned 40 this morning :oops:

Ami Pro is an old Lotus word processor product.

I meant AmiBroker.

- Forum Mgmnt

JT
Roundtable Fellow
Roundtable Fellow
Posts: 81
Joined: Tue Apr 15, 2003 6:27 pm
Location: Washington

Post by JT » Fri Jan 16, 2004 4:46 pm

First. Happy Birthday c.f.!

Second, please, please, please don't make it like wealthscript. Learning a Pascal type language or whatever, really isn't a top ten priority for me.

I'd consider doing a hybrid of TR and EasyLanguage. I like how TR uses an Excel like columns. It makes it very easy to check your code and see how your indicators and variables change day by day.

I also like how it has different modules for applying entries, moneymanagement and exits.

However, the TR language itself seems a little limited as compared to EasyLanguage. As Bondtrader mentioned, you have no ability to change or even check the code of the built in indicators.

Ideally, a combination would take those good aspects from each application and expand them and make them even better!

my .02
JT

Murray
Senior Member
Senior Member
Posts: 33
Joined: Mon Jul 07, 2003 1:56 am
Location: Sydney, Australia

Tradestation

Post by Murray » Fri Jan 16, 2004 9:12 pm

Good or bad - Tradestation has a lot of support material to help educate people on coding.

verec
Roundtable Knight
Roundtable Knight
Posts: 162
Joined: Mon Jun 09, 2003 7:04 pm
Location: London, UK
Contact:

Post by verec » Sat Jan 17, 2004 6:56 am

The syntax aspect of your new language is mostly a "taste" thing (begin or no begin, braces, semicolons, etc...) while the "library" aspect is probably more profound.

But then it depends on a well defined set of appropriate abstractions.

What is a Portfolio?
How does the Portfolio keep track of the trades?
Are the trades included in the Portfolio or some other container?
What is a "Set of rules" ?
What can a set of rules access (quote data? indicators?, equity?)
Are all your indicators prebuilt? Or can the user define new indicators?
How is "money management" defined? Is it "orthogonal" to the rules? Embedded?
How can I mix and match entry/exit rules and MM rules?
How can I have entry/exit rules that are valid for entering, but another set of entry/exit rules for "adding to a position" or "reducing exposure" ?

It seems to me that, regardless of the syntax, again, the "language" should first expose a "Trading Model" where you have defined such things above, and how they're supposed to interact.

My current thinking (for PlugYourOwn) is that:
Portfolios are containers of other Portfolio -- recursively -- This allows you to both deal with OPM by spreading your capital across many "accounts" where one account is one (set of possibly nested other) portfolio, and to play "what if" scenarios inside a "non-active" or "non-trading" Portfolio while others are put to real work.

Portfolio are also containers of trades, and then you have your "Set-of-rules" that I call a strategy. Each strategy can refer to a number of indicators (it is for you to decide whether they are prebuilt or user definable), money management rules and "ongoing trade following" rules ("trade", not "trend")

In Summary, my first candidate set would include:

- Portfolio
- Trade
- Indicator
- Strategy (out-of-trade entries/exit)
- OTF (Ongoing Trade Following when to add position/reduce exposure)
- Money Management

Because it fits nicely with an OO model, I've chosen Java as the language for my own stuff, but obviously, you have far more resources than I do, so, inventing a language of your own might be appropriate. But I've seen so many bad "Roll-your-own" languages over the years ... The primary reason is that poeple tend to build a language that is domain specific (and being domain specific is a good thing) but then forget the basics of what language constructs are required to become Turin complete.

In other words, I'd rather favor a small, domain agnostic language, with all the domain entities expressed as "things you can build with that language", ie, the C++ or Java way, as opposed to a monolithic block that includes everything and the kitchen sink like Lisp or Forth (It's a bit unfair to both of them, but that's the idea).

That's my view. Hope this helps.
Last edited by verec on Sat Jan 17, 2004 8:04 am, edited 1 time in total.

Forum Mgmnt
Roundtable Knight
Roundtable Knight
Posts: 1842
Joined: Tue Apr 15, 2003 11:02 am
Contact:

Post by Forum Mgmnt » Sat Jan 17, 2004 8:03 am

Thank you all for the comments so far.

We've had 17 votes but only a few comments.

Those of you who voted for specific languages, why did you do so?

Those of you who didn't, why not?

Philemon
Senior Member
Senior Member
Posts: 40
Joined: Fri May 30, 2003 3:48 am
Location: Thessaloniki, Greece

Post by Philemon » Sat Jan 17, 2004 12:35 pm

I have voted for TR (answering to the question above that stresses MOST).

However, I'll have to second JT's and Bondtrader's remarks.

and although, not syntax related, this is my most important list:

a. Most important likes: 1. the pages 2. the grid
b. Most important dislikes: 1. Bondtrader's no.9 (i.e. I want to be able to
access my code for a new idea for exits from any or all of the already coded systems) - user code could be grouped as entries, exits etc.
2. The limited way (not straight forward) TR handles open trades' size

Could "Systems" also (but not exclusively) be defined by checklists? What I mean is the following: If pages ala TR (Resources, Trade entry logic, Trade in progress/ exit logic) and b1 could be incorporated a user would be able to check (choose) the predefined "functions" for entries, exits (per group mentioned above). Of course, it would be up to the user to pass uniformly named variables from one page to the next. I should probably have put this one in a "Veritrader wish list" topic I saw somewhere but anyway.

Forum Mgmnt, thank you for asking.

Mark_et_Lizard
Roundtable Fellow
Roundtable Fellow
Posts: 62
Joined: Sun Apr 20, 2003 9:16 am

Post by Mark_et_Lizard » Sun Jan 18, 2004 7:20 am

I voted for TS because that's the only language I know. I'm sure I'll have trouble (dope that I am) no matter what language is chosen so my biggest concern would be the availability of support, forum help and paid help. TS used to charge $150 minimum to code even if it was just a few lines. They've come down to $50 minimum but most questions can be answered by the online network. I still think it's vital that people be able to protect their codes and ideas, so they can share them and profit from them, yet protect their intellectual property. Grand theft is but a cut and paste away these days. On the other side of the coin, it would be nice if there were someway it could be verified that the code of a system one purchases is not just cut and pasted from some one else, changed ever so slightly and re marketed as one's own. I think the system developers market needs something like the commissioner of baseball, to keep things honest. If Veritrader becomes a dominant industry standard perhaps there could be a rating system to let people know one system is basically copied from another with a minor change. ( I also think minor changes can be incredibly valuable and make the difference between profitability and extreme profitability) If there Veritrader allowed verification of code through a backdoor there would also need to be checks and balances prevent Veritrader from using every ones idea for their own profit.

Lots of Love Lizzy

William
Roundtable Knight
Roundtable Knight
Posts: 238
Joined: Sun May 04, 2003 4:41 pm
Location: Manhattan, New York

Wish List for 2.0 Programming and Features

Post by William » Sun Jan 18, 2004 10:45 am

From a non-programming point of view, i think the best thing you can do is to make the language simple (HighestHigh) but robust and intuitive. It has to be a language that is easy to start from ground zero and get relatively complex after some "brief study"

A library of popular codes and commands that deal with entry, exit, pyramiding, risk management, position sizing, correlation etc., i think would make things easier. TS has those small building blocks where you can mix and match certain ideas so you could be a pseudo programmer pretty easily...

Tutorials or lessons in the help guide would also be huge.


Not sure if this is common or easily done, since i have no experience, but if an error was made in the programming it would be good if the illogical part were highlighted and a possible solution or detailed explanation were presented to help the user back out of their error.

Not sure if this would be eailiy done, but i think it would be very cool to have....

.... a small preview lab of sample price that allows the user to see what he is building, so as each additional line of code or action is created, you could have a small sample price set window and you could preview each building block being added for accuracy and completeness. For a non-programmer, i think the preview mode woulld help the user visualize what he is creating through code.

For example say i added the 5 and 20 day moving average code. In the sample window, two moving averages are thrown in. Then, i say i want to do an entry on a cross. Well, then there would be a entry signal created and an entry would be fired on the cross. Then if i were to add another line of entering after a cross but only if/once price managed to close above the intra-day high of the day that the signal fired. Once that was added, i could look at the preview lab and see if what i entered was what i intended to do. That way i could be confident that once deployed on a mass scale, it would be correct. I find it can get a little overwhelming to scan through the trades and make sure it fired correclty...but maybe thats just me..

Bernd
Roundtable Knight
Roundtable Knight
Posts: 126
Joined: Wed Apr 30, 2003 6:39 am

Post by Bernd » Mon Jan 19, 2004 7:28 am

:wink:
Last edited by Bernd on Fri Apr 18, 2008 3:09 am, edited 1 time in total.

2010
Contributing Member
Contributing Member
Posts: 5
Joined: Sun Aug 17, 2003 4:37 pm
Location: British Columbia, Canada

Post by 2010 » Mon Jan 19, 2004 4:22 pm

I agree with Bernd. Making the Veri Trader language work from a standard programming code would be so with it. I'd rather spend my time learning a regular programming language. Just my .02

Forum Mgmnt
Roundtable Knight
Roundtable Knight
Posts: 1842
Joined: Tue Apr 15, 2003 11:02 am
Contact:

Post by Forum Mgmnt » Mon Jan 19, 2004 11:39 pm

Bernd, 2010,

The benefits you outline for not inventing a new language are the reasons we decided to use Visual Basic syntax for VeriTrader's language. Many people already know that language, so they won't have to learn anything except our trading-domain-specific object model and functions.

There are lots of reasons that it makes sense to use a relatively simple language for this sort of thing. One of the biggest being that we don't want to require anyone to buy a development language or environment. Also, by building our language processor directly into VeriTrader, we can offer a very tightly integrated environment that is more powerful and easier for the typical person to learn and use.

A problem with .NET in particular, is that despite Microsoft's heavy marketing otherwise, IMO, the .NET platform is not ready for prime time for commercial application delivery. Requiring your users to install the .NET runtime is not something most commercial software developers want to do.

You will also be able to write code in C++ as well, if you really want to get down and dirty. However, this will be considerably more difficult for those who aren't experienced. It will also be harder for those who are experienced programmers because you will have to work in an environment like Visual C++ and then switch to VeriTrader to test. In contrast, the VeriTrader Basic environment will be tightly integrated with VeriTrader, so you will be able to make changes and test them without leaving the VeriTrader application.

I think once you see the complete system, you will like our approach.

- Forum Mgmnt

Bernd
Roundtable Knight
Roundtable Knight
Posts: 126
Joined: Wed Apr 30, 2003 6:39 am

Post by Bernd » Tue Jan 20, 2004 3:13 am

:wink:
Last edited by Bernd on Fri Apr 18, 2008 3:09 am, edited 1 time in total.

Forum Mgmnt
Roundtable Knight
Roundtable Knight
Posts: 1842
Joined: Tue Apr 15, 2003 11:02 am
Contact:

Post by Forum Mgmnt » Tue Jan 20, 2004 7:51 am

I want to bring up another point, which you might want to take into consideration while designing the software: I usually deny using development environments without basic debugging capabilities like simple breakpoints, step by step execution, a call stack and a watch list for variable values.
Well, you're going to love 2.0, our integrated debugging environment will be the most powerful available for a trading system platform. I don't want to get into too many specifics yet, but suffice it to say that I consider debugging to be as important, if not perhaps more important than any other language issues.

toho
Contributor
Contributor
Posts: 3
Joined: Thu Dec 18, 2003 10:00 am

Windows Script Technology

Post by toho » Thu Jan 22, 2004 10:15 am

You might want to look into Windows Script Technology. It provides a way to plug in MS VB (or any other script engine with the right COM interfaces, such as JavaScript) into any application. There is also some support to hook in debuggers. This is the same interface MS use for most of its apps to get scripting.

Forum Mgmnt
Roundtable Knight
Roundtable Knight
Posts: 1842
Joined: Tue Apr 15, 2003 11:02 am
Contact:

Post by Forum Mgmnt » Thu Jan 22, 2004 10:27 am

We did look seriously at the Windows Scripting interface about 9 months ago, but decided it limited us too much.

At this point, the basic languge processor is in and working, we're working on the object and function library, so we won't be changing that anytime soon.

- Forum Mgmnt

cache
Contributor
Contributor
Posts: 2
Joined: Sun Jan 25, 2004 10:07 pm

VeriTrader 2 VB language

Post by cache » Sun Jan 25, 2004 10:39 pm

Hi Everyone:

Fantastic website!

Should I be studying VB 6 in order to take full advantage of VeriTrader 2's potential?

I am not a programmer (I took fortran in college years ago).

Secondly, if Veritrader 2 is as powerful and creative as c.f. intends, is it necessary to learn C++?

I've read so much about the limitations traders eventually experience when using the products currently on the market.

The message has always been -- learn C++ now or you'll wish you had later regardless of TR, Wealthlab etc.

Post Reply