Language of the future

Python code is quite slow too.

http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php

However, Python is very productive for many tasks. For a website, one can usually scale by having more machine. For trading, I think it depends on the frequency of your strategies.

BTW, if someone wants a job in a web start-up, knowing Python is a definitely advantage right now. (Who knows, a few years back Ruby-on-Rails was the rage.)

 

Articles or talks by Yaron Minksy of Jane Street regarding why they use OCaml might answer a lot of your questions. OCaml and F# are very similar.

 

I'd like to add Erlang with its powerful concurrency capabiities to this list.

 

Really, who cares?

Automated trading applications rarely get very large. Most applications (especially the ones we're discussing on this site) will be maintained by either a single individual, or a small team.

All of the standard computer science "knowledge" that applies to systems programming really is irrelevant here. Almost all of the above was intended to deal with code or system maintenance/reliability issues, for very large applications (ranging in the millions of lines of code + thousands of developers + tens of years of life cycle). You're wasting your time worrying about these things.

I agree with the earlier person. I've been programming systems/applications since 1987, and I really have minimal interest in any specific "language". They're all inter-changeable, depending on what you're trying to do, and how quickly you're trying to do it.

I personally would just look for the easiest step forward, and take it one step at a time. For my current automated trading application, I've already moved through 3 platforms/languages... never put too much thought into the flavor I was using at a specific time, just get it done.

I will say, using something plugged into .NET (or Java) has one significant advantage: extensibility. My code uses Amazon EC2 as a datastore, and I've also used other third-party serialization/logging/visualization libraries. If I ever added a database component, then I have a wide range of sql interfaces. You don't want to futz around with erlang making that work.

 

Yes. I love those talks. I always liked the ML family.

I think F# is more practical for most people because it has access to everything .NET has to offer. It is not straightforward to interface OCaml other languages and it is certainly costly for individuals or small groups to build the whole infrastructure in OCaml.

Speaking of which, I believe any undergrad-level introduction to programming class should use an object-functional language like OCaml or F#.

Erlang not only has support for serious concurrency, it also has mechanisms for fault tolerance and hot loading.

How do I add new entries to the poll?

 

This sentence is false.

 

I've been using IronRuby for the last year, I've found it works very well as I'm able to go from idea to a working script in no time flat. Performance is not amazing, but the majority of my ideas do not require performance.

For the evaluation (note that pretty much every point also applies to JRuby, the implementation of the language within the Java virtual machine):

1. memory management (GC vs unmanaged)

Uses .NET garbage collector, which is pretty solid. It tends to use a bit more memory than the equivalent VB.NET or C# script, but that's alright. RAM is cheaper than my time.

2. concurrency model

Again, uses .NET threads which are fairly solid. You can use any of the classes in the .NET library for concurrency.

3. static typing vs duck typing (or better yet, type inference)

Ruby uses duck typing. Mixins (aka traits in Scala) means you can write code in chunks and mix-and-match them per script. For example, you could have a SpreadTrade mixin that you just drop into a script and it will make the script do spread trading.

There is a bit of clunkiness when interacting between C#/VB.NET code and IronRuby code due to type conversions and what-not - since Ruby collections can contain an arbitrary mix of types, collections are always treated as collections of Object when passing into C# code.

4. object-oriented programming vs functional programming

Ruby has a very nice blend of both. Absolutely everything is an object (including classes and primitives like integers), existing classes are open (you can add methods to existing classes), and closures passed to methods have a rather succinct syntax. For example, it is possible to build a library where the following code is valid:

Code:

symbol.changes_by 2.5.percent do
  # now within a closure with some code to execute when the stock changes by 2.5%
end

At the same time, you still have all your nice functional programming techniques:

Code:

# higher order functions:
(1..5).map { |i| i * 2 }   # produces: [2, 4, 6, 8, 10]
(1..100).select &:odd?     # gets all the odd numbers from 1 to 100
(1..100).inject &:+        # produces the sum of 1 to 100

# currying
f = lambda { |a, b| a + b }
g = f.curry[1]
g[2]          # produces 3

Two new criteria that could be added:

5. Meta-programming. In Ruby not only are things dynamically typed, but types themselves are dynamic. Rather than manually coding something every time, I can write one line within a class that will automatically generate the code that I want:

Code:

class SomeOrder
  # this code will automatically generate code to cause orders of type SomeOrder to be
  # hedged by an object of SomeOtherOrder
  hedged_by SomeOtherOrder

  # generate code that will cancel the order on some condition
  cancel_if {
    # market is tanking
  }

  # etc.
end

This allows you to write code in a more declarative way, which can lead to less bugs as there are less moving parts you have to manually specify each time.

6. Readability: As demonstrated in the examples above, I can show my scripts to non-programming traders and they are able to follow the strategy fairly easily. They may not understand the meaning of the punctuation, but the flow of the logic can be set up in a way similar to the way they might describe the strategy in English.

Some downsides:
- Like I said, performance is not amazing, it's on par with Python and the other scripting languages.
- When coming from static languages it is inevitable you will get frustrated the first time you stub your toe on the dynamic typing system - you can get some weird bugs when you accidentally pass in a string instead of an array or something like that.
- Those nice declarative meta-programming things can be rather tricky to implement within a library.
- Finally, the language assumes that everybody knows what they're doing. It is possible for some people to write very bad code in Ruby that messes things up - for example, overriding the + operator for arrays to implement vector addition when the standard library has it defined as the array concatenation operator. Imagine your surprise when [1, 2] + [3, 4] produces [4, 6] instead of the expected [1, 2, 3, 4].

 

Interesting thread, How about the languages like Microsoft .NET, C#?

 

I remember coding in Ruby a few years ago. Dynamic typing is great if you have a close knit team of good programmers. It really allows test-driven development (static typing requires at least an interface).

However, it is not very nice to automated refactoring, at least not without excellent unit-testing coverage.

Meta-programming is fun though.

RE: Microsoft.NET

Microsoft is doing a good job here. Check out F#. It integrates with the rest of .NET very well without being overly ambitious (e.g. Scala). I fell in love with F# instantly.

Even C# (4.0) is a better language than Java (7), IMHO. Java is still without closures and its generics is way too wild (e.g. wildcards).

 

Natural language can be disambiguated if you build in enough knowledge of the context. See IBM's Watson, which could understand Jeopardy clues.