That is somewhat similar to what I've experimented with. (well not the same naming). Anyway... what you are showing is not not Linq, just fluent interfaces/ methods. If it should be Linq it would take an expression/ functional represention as input... for instance: Code: RealtimeData .ApplyIndicator((name, y) => name = "ma3", y => y.MovingAverage(d => d. Price)).Length(3) etc... .SendOrders();
Worth spending the time to watch: http://channel9.msdn.com/shows/Goin...-Meijer-Inside-the-NET-Reactive-Framework-Rx/ This is more inclusive: http://codebetter.com/blogs/matthew...ntroducing-the-reactive-framework-part-i.aspx
Has anybody used Haskell as part of a trading system ? I've used it for small components like automating pulls of data from the web and using the probability monad for working out optimum position sizings but I was thinking of going a lot further and perhaps writing a FIX adapter and a little framework for running strategies. Just wondered whether anybody else has done anything serious in it. I've also had a play with OCaml, F# and Scheme and have found Haskell to be the most impressive functional language so far and I know that it is used within a few investment banks.
If you are in MSFT .NET environment, it seems that F# is a natural choice because you can embed the language in your application at runtime very easily. It is a built-in scripting language out of the box that couples with the underlying C#.NET, C++.NET, and VB.NET very easily. I have always believed that unless extreme speed is necessary, your business logic should be in a dynamic scripting language. The hard part is designing your system to be manipulated not by code you wrote, but by a scripting language at runtime. I haven't done this yet, but it is on my list.
Thanks for the well wishes. As far as development goals, what is the point of going through life just being good enough? Live your life so that when you die, you left nothing on the table with nothing left to give, and have no regrets.
A software developer <i>and a philospher too!</i> I look forward to Mr Nitro's line of inspirational books and DVDs...
Philosophy is when you tell other people how they should live their lives. Since I am talking about myself and the way I approach things (at least I mean to), this would be better categorized under, Code of Personal Honor, imo. I have friends that swear by inspirational videos though....I never underestimate the power of motivation, where ever it comes from.
I realize that these people start these documents with definitions and all the mumbo-jumbo that a mathematician needs and requires. However, this doesn't motivate someone who is not a professional in the field to get interested. Here is the key notion. Monads allow a natural way to compose objects. This is at the root of Category Theory. It is "composability" that allows for fluent interfaces, which makes code local and so much more readable. The reason this is tied to Category Theory is that in Category Theory we are interested in the arrows and not the objects themselves. A mathematician would say, [objects] "up to isomorphism". In a sense, Object Oriented programming and Generic Programming already is Categorical, since it allows us to program to interfaces, and then our code [generic functions] can be made to work "up to isomorphism" of any object of type T. The reason that Category Theory is such a natural place to explore these things is because Category Theory is a subject that provides a uniform model of set theory, algebra, logic and computation. All of those underlie theoretical computer science, and language theory in particular. I am beginning to believe that the right way to learn functional programming (other than being a mathematician) is to learn Haskell and forget all the other languages. Once you know this one, the rest fall into place and all you need to do is learn the syntax of a particular functional languate. In essense, we want to be able to compose our objects into programs in the same way we compose numbers: x = 5 * 2 + 3 - 1 / 10 Notice that the numbers are not important - you could just as easily abstract by saying x = a * b + c - d / e it is the functions (operators, in Category Theory, Functors) and that they are composable that is important. *, +, - and / are Monads! Everyone understands this program. Highly recommended reading is: http://stackoverflow.com/questions/1012573/getting-started-with-haskell
Btw, the logical conclusion of all of this is to do for programming what spreadsheets did for numbers, allow anyone to be able to easily manipulate (compose) programs as objects as easily as spreadsheets manipulate numbers. In the future, programmers will simply write monads. Monads are the apple apps of the future for some unknown application that will allow us to easily compose them. In the future mathematicians will use the same app to write their papers, and even someone on the street will be able to follow Deligne's proof of the Riemann hypotheses over finite fields.