DSL for trading

Still not sure it makes sense. Nice example, but now add the comlex stuff - multiple signals, trading logic.... without making it either a SQL style of debugging hell (i.e. one hugh statement without a proper debugger), or.... well... a generic programming langauge ;)
 
Quote from chvid:

I'd be interested in participating.

For my own setup I originally had a DSL I used for genetic programming but now I just have a single Java class and then use dependency injection, static imports and annotations to get a more concise definition of my trading system.

This is thread on subject from nuclearfinance:

http://nuclearphynance.com/Show Post.aspx?PostIDKey=116620
Thanks. It would be a big project, but worth well doing.

That link to NF is interesting. I have done more extensive research on it, and it looks like a good way to do it in .Net is using

http://www.codeplex.com/ometasharp
 
Quote from TSGannGalt:

Somewhat agree...

As nitro's 2nd example in his 1st post, if you're dealing with Pairs and Greek Arbs, Flow Hedges and other types of multiple legged trades... DSL helps out. Personally, all my trades are done within the normal semantics because I'm the only one using it. But I can see the benefit of it when there are multiple people handling the dev.

I know a firm that has a SQL like DSL that does things like:

Code:
"TRADE 
      SYNTHETIC_ATM_STRADDLE(OPTION.DELTA_NEUTRAL)
FROM 
      OPTIONS
INNER JOIN
      UNDERLYING
      ON UNDERLYING.SYMBOL_CODE = OPTIONS.UNDERLYING_CODE
WHERE
      OPTION.DELTA >= 1     
      AND UNDERLYING.CORP_ACTION != '1'
      AND UNDERLYING.REGION = 'US';"

* The example above in not what that firm exactly uses but it's based on what I've heard from the chick. But from she said, the query is like a SQL SELECT statement that uses TRADE instead of SELECT. Each data column represents a set or a single leg. From is the Data source. Where statement is the Analytics. Also, by changing the "TRADE" to "DISPLAY", the app. outputs a string result of the query.

I thought it was cool....
SQL would make a good DSL, and I have often thought about building on top of it.
 
Quote from NetTecture:

I am not sure a DSL makes sense. See, the main problem is that trading decisions fall into the normal programming langauge paradigm. Yes, you need some methods to do the trading, but that is just methods.

DSL are normally used when normal programming semantics do not fit. Example: SQL DDL (data definition language) expresses things that one can not normally express within a programming language (note: constructing an object tree is not the same as expressing something in the langauge).

As I said, I do not think trading is something that widely benefits from a DSL approach.
A DSL makes perfect sense. I believe most of if not all of you are missing the number one reason to implement a DSL: once in place, it makes testing new systems and ideas almost trivial. Your productivity in terms of research explodes.

One of my mentors in programming told me very early on, the best programmers don't program a solution to a problem, they implement a mini language in which the domain is naturally expressed, and then implement the solution in that system. I have never forgotten that and every day I measure how good a programmer I am by how well I am able to do this.

So, if you needed a system to do rendering of documents, you don't program the system to render documents by running a C# program, you invent the .pdf format, and you run an interpreter capable of reading and rendering .pdf formats.
 
I was told: Programming is about choosing the right set of primitives.

The query languages of complex event processing systems look a lot like SQL:

http://esper.codehaus.org/
http://coffeeonesugar.wordpress.com/2009/07/21/getting-started-with-esper-in-5-minutes/

From the example below - embedded in some Java code:

Code:
select * from StockTick(symbol='AAPL').win:length(2) having avg(price) > 6.0

I remember the first editions of Hibernate; their "HQL" language was simply SQL with some search and replace - so this is not necessarily that hard to implement.

One idea that you toy could with if you had an event query language is to bind the language together with standard Java/.NET via annontations/attributes:

Code:
public class MyFirstTradingSystem {
  @OnEvent("select * from ticks where price > 30.00 and symbol like 'J%'")
  public void execute(Event event) {
    // handle the filtered ticks in some standard Java code
  }
}

Another interesting platform - focused on model-building / model-exploring:

http://www.quantmod.com/

Which sits on top of R.
 
I like you idea of raising an event on a pattern match native in the language. Also, thanks for the interesting links.

I will point out that this idea sort of already exists with LINQ, if you made it "realtime". Here is an attempt to do just this:

http://www.codeplex.com/clinq

It is still immature to use, but it is the right idea, imo.
 
Back
Top