How to design a programming language adapted to financial instruments? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers. Closed last year. Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.

I work for a boutique specialized in finance.

We thought about designing a language to describe financial entities related to financial markets.

This would be mainly used as some kind of scripting language to replace many process run in spreadsheets and VBA macros.

It has to be simple and it has, in fact, to call various C++ and C# libraries behind the scenes. It has to let users handle abstractly objects which could represent time series (intraday and daily).

It has to be fully debuggable, when an user will have an issue, we must be able to step in the C++/C# code and reproduce the bugs. Ideally it has to be able to be launched via some mechanism within Excel and return the results within Excel. (unfortunately almost every person working in Finance is using Excel)

If you had to do this task, how would you go about it ?

Would you go for a functional syntax ?

Would you develop some scripting language which would be interpreted or would you compile it in another language (like converting the scripts in C++ or C#) ?

I did not find any open-source project for this kind of development, but is there any commercial product开发者_StackOverflow using this kind of syntax ?

EDIT: I read all your answers but I will wait more time before to pick an answer. They are all very useful opinions though !

EDIT2: I marked High-Performance Mark's as solution. All your replies are very useful and I have modded all of them up. He was one of the first answers and his reply is quite insightful for us.

---

I suggest that you concentrate on developing a rich set of classes in your preferred OO language (either C# or C++, though I suspect you might find it easier to integrate the former with Excel). That would give you your language to describe financial entities related to financial markets. When you've done that you should consider whether to continue to wrap these classes in some Domain Specific Language, or simply to expose them to your user community.

I suspect that your domain has some irreducable complexity and that an intermediate DSL will have to be (nearly) as complex as your set of classes and that, therefore, you have little to gain by creating it.

Another approach would be to integrate Excel with Mathematica for which Wolfram produce a toolbox of some sort. I have no experience of this, but Mathematica is certainly suitable for any of the computations you'll have to do.

Regards

---

I would wrap the C++ libraries in Python.

I would define a package of fluent classes that -- in effect -- was my domain-specific language.

I would use the Python language directly based on those two foundations. I would not invent my own new syntax. The world doesn't need Another Syntax; we have syntax and grammars enough to parse, enough to last till the end of time.

Would you go for a functional syntax ? Python has functional capabilities. If you're careful with your Python class design, you can achieve a clean functional style.

Ideally it has to be able to be launched via some mechanism within Excel and return the results within Excel.

Since the Python interpreter can be embedded in a C++ (or C#) application, you can easily create Excel API's. From Excel to your new language, do as little as possible in the C++ API to initiate the Python functionality.

BTW, your competition is Resolver One. This is what they do.

---

Another viewpoint which leverages c#.

As you already have a powerful general purpose functional programming tool your users are familiar with and have bought into in the shape of Excel I would look to build a solution around that. You still get the option that way of being able to use other 3rd party add-ons and integrated options (e.g. R and Mathematica)

I would look into Managed Automation Add-ins for User Defined Functions. These are essentially c# library projects that use the System.Runtime.InteropServices as described in this article link text. To the users these functions are added at a cell level in the normal way using the function wizard and can be more or less what you want them to be. This then is your DSL. Users can choose to integrate the functionality in their existing models easily. It would also be fast to prototype something to test the feasibility of this. These are fully debuggable.

Additionally using Visual Studio Tools for Office you can access the full excel object hierarchy and even add action panes which can be laid out by dragging and dropping controls for more complex data entry requirements. I believe it is even possible to use WPF with Excel in this way if you needed to add specialised visualisations. If you needed to persist data back to say Sql Server you could build a turn around validation form using this approach.

I sound like a M$ shill! (Just to set the record straight I do not work for them).

You would need to evaluate the performance of this and I am not sure how it would scale.

---

Simon Peyton-Jones of Haskell fame contributed to a paper 'Composing contracts: an adventure in financial engineering' which discussed how functional languages lent themselves to composing executable descriptions of financial derivative contracts. Such a method should be possible with F#.

I believe the offerings of LexiFi aimed to commercialise some of this research.

---

Jane Street Capital uses OCaml, and wrote up their experiences here. It's a pretty interesting if broad read.

For your environment, if you followed their model, you could use F#, which started out life as an OCaml dialect, but which of course runs in the .NET world.

---

If your underlying library uses Java you should take a look at doing a DSL in Groovy. There are a number of podcasts and article about this, try Googling "DSL Groovy".

---

Most number-crunching financial institutions (or divisions therein) have already acquired Matlab licenses. I recommend that you take a look at the Object Oriented facilities offered by Matlab (and, indeed, at their Financial Toolbox).

Up front I think you gain three things:

1) Access to a high-level environment where users can concentrate on the problem and not on the implementation 2) Availability of high-quality graphics 3) Seamless integration with Excel and other productivity packages

I know you mean to develop a Language (as opposed to an application) but consider piggy-backing your semantics to a well know language - this way you avoid the learning curve for your users.