views:

452

answers:

8

I'm currently working on a component of a trading product that will allow a quant or strategy developer to write their own custom strategies. I obviously can't have them write these strategies in natively compiled languages (or even a language that compiles to a bytecode to run on a vm) since their dev/test cycles have to be on the order of minutes.

I've looked at lua, python, ruby so far and really enjoyed all of them so far, but still found them a little "low level" for my target users. Would I need to somehow write my own parser + interpreter to support a language with a minimum of support for looping, simple arithmatic, logical expression evaluation, or is there another recommendation any of you may have? Thanks in advance.

+1  A: 

Custom-made modules are going to be needed, no matter what you choose, that define your firm's high level constructs.

Here are some of the needs I envision -- you may have some of these covered already: a way to get current positions, current and historical quotes, previous performance data, etc... into the application. Define/backtest/send various kinds of orders (limit/market/stop, what exchange, triggers) or parameters of options, etc... You probably are going to need multiple sandboxes for testing as well as the real thing.

Quants want to be able to do matrix operations, stochastic calculus, PDEs.
If you wanted to do it in python, loading NumPy would be a start.

You could also start with a proprietary system designed to do mathematical financial research such as something built on top of Mathematica or Matlab.

Paul
+7  A: 

It sounds like you might need to create some sort of Domain Specific Language (DSL) for your users that could be built loosely on top of the target language. Ruby, Python and Lua all have their various quirks regarding syntax, and to a degree some of these can be massaged with clever function definitions.

An example of a fairly robust DSL is Cucumber which implements a an interesting strategy of converting user-specified verbiage to actual executable code through a series of regular expressions applied to the input data.

Another candidate might be JavaScript, or some kind of DSL to JavaScript bridge, as that would allow the strategy to run either client-side or server-side. That might help scale your application since client machines often have surplus computing power compared to a heavily loaded server.

tadman
Tcl is excellent for implementing DSL's
glenn jackman
Ruby is particularly good for writing DSLs (optional parentheses and blocks facilitate this). Check out this article by Martin Fowler on Ruby's Rake: http://martinfowler.com/articles/rake.html
banister
A: 

This might be a bit simplistic, but a lot of quant users are used to working with Excel & VBA macros. Would something like VBSCript be usable, as they may have some experience in this area.

Paddy
A: 

Existing languages are "a little "low level" for my target users."

Yet, all you need is "a minimum of support for looping, simple arithmatic, logical expression evaluation"

I don't get the problem. You only want a few features. What's wrong with the list of languages you provided? They actually offer those features?

What's the disconnect? Feel free to update your question to expand on what the problem is.

S.Lott
Great point S.Lott, I made the mistake of not seperating out power users from beginners. I'm planning on including Ruby for scripting now for said power users.
Pierreten
+7  A: 

Mark-Jason Dominus, the author of Perl's Text::Template module, has some insights that might be relevant:

When people make a template module like this one, they almost always start by inventing a special syntax for substitutions. For example, they build it so that a string like %%VAR%% is replaced with the value of $VAR. Then they realize the need extra formatting, so they put in some special syntax for formatting. Then they need a loop, so they invent a loop syntax. Pretty soon they have a new little template language.

This approach has two problems: First, their little language is crippled. If you need to do something the author hasn't thought of, you lose. Second: Who wants to learn another language?

If you write your own mini-language, you could end up in the same predicament -- maintaining a grammar and a parser for a tool that's crippled by design.

If a real programming language seems a bit too low-level, the solution may not be to abandon the language but instead to provide your end users with higher-level utility functions, so that they can operate with familiar concepts without getting bogged down in the weeds of the underlying language.

That allows beginning users to operate at a high level; however, you and any end users with a knack for it -- your super-users -- can still leverage the full power of Ruby or Python or whatever.

FM
Very quality answer; thanks. I guess most of us should realize that we aren't language designers, we're developers! I like the idea of designing GUI based tools in conjunction with a script interface for my power users; truly the best of both worlds.
Pierreten
A: 

I would use Common Lisp, which supports rapid development (you have a running image and can compile/recompile individual functions) and tailoring the language to your domain. You would provide functions and macros as building blocks to express strategies, and the whole language would be available to the user for combining these.

Svante
A: 

Define the language first -- if possible, use the pseudo-language called EBN, it's very simple (see the Wikipedia entry).

Then once you have that, pick the language. Almost certainly you will want to use a DSL. Ruby and Lua are both really good at that, IMO.

Once you start working on it, you may find that you go back to your definition and tweak it. But that's the right order to do things, I think.

Shadowfirebird
A: 

Is something along the lines of Processing the complexity level that you're shooting for? Processing is a good example of taking a full-blown language (Java) and reducing/simplifying the available syntax into only a subset applicable to the problem domain (problem domain = visualization in the case of Processing).

Here's a little side-by-side comparison from the Processing docs.

Java:

g.setColor(Color.black)
fillRect(0, 0, size.width, size.height);

Processing:

background(0);

As others have suggested, you may be able to simply write enough high-level functions such that most of the complexity is hidden from the user but you still retain the ability to do more low-level things when necessary. The Wiring language for Arduino follows this strategy of using a thin layer of high-level functions on top of C in order to make it more accessible to non-programmers and hobbyists.

awesomo