best language for quantiative finance? C, D, Fortran,python etc.

[Sparohok]

Quote from mrtwo:

If you were stripped of all 'investment' you made in a certain platform/language, would you make the same choices again?

I could learn a language with zero effort, I would learn Matlab and Ruby and use them for some of the things I do now in Python.

Martin

 

[mrtwo]

Quote from Sparohok:

This isn't a matter of fluency. I've been writing C++ code for 20 years and Python code for 2 years. I'm far more productive in Python.

It is a simple tradeoff between the programmer's time and the computer's time. I know whose time I'd rather waste.

Martin [/B]

Maybe our dynamic here is different because we have a team in place with a very formal development process and in our case, our C/C++ team is among one of the most productive teams in the house.

But as I said on the other post, I am not sure I would be developing anything in C/C++ if I were stripped of all our previous investment on it (libraries, patterns, pratices, etc)

Martin, I already asked nononsense and I would like to hear from you too: what, in your opinion and own words, makes Python the best language for you?

 

[nononsense]

Quote from mrtwo:

I would like to hear your subjective experience though. What was the tipping point for you, why did you chose Python over all other options? I am pretty sure you can name a few things that you saw in Python that 'did it' for you and that if shared, it could make people consider giving it a try

mrtwo,
I feel that I did more than my "job" here.
In fact, there is a lot more required to get started: GUI, DB interface, IDE, libraries. I explained all this a couple of times over during the last 12 months or so. Make some effort yourself and do a little search at ET. You'll find what you want.
Better still, stick to www.python.org as a starter. They know much better than my second hand know-how.
I can assure you though that YOU WON'T BECOME PROFICIENT in Python in one week like some wise guy wrote, perhaps a bit if you only aspire to kiddie exercises.
I'm working 2 years on it and I keep on picking up new "nuggets".

 

[Sparohok]

Quote from mrtwo:

What was the tipping point for you, why did you chose Python over all other options? I am pretty sure you can name a few things that you saw in Python that 'did it' for you and that if shared, it could make people consider giving it a try

I think for me, in this line of work, it wasn't Python itself that sealed the deal, it was numarray. Numarray is a package that turns Python into an array language like Matlab or APL.

http://en.wikipedia.org/wiki/Array_programming_language

Something like numarray could be written in C++, and probably has been, but the Python object model and syntax make it particularly clean and expressive.

Without numarray, I think pure Python would be too slow for a lot of the stuff I do. I would have had to write a lot more embedded C code for the core numerical algorithms.

Here's an example of the power and compactness of Python and numarray. This calculates the correlation, alpha, and beta of two vectors a1 and a2 in a dozen lines of code.

<pre>
def Correlation(a1, a2):
assert len(a1) == len(a2)
n = len(a1)
mean1 = sum(a1) / n
variance1 = sum( (a1 - mean1)**2 ) / (n-1)
mean2 = sum(a2) / n
variance2 = sum( (a2 - mean2)**2 ) / (n-1)
covariance = sum( (a1 - mean1) * (a2 - mean2) ) / (n-1)

beta = covariance / variance1
alpha = mean2 - beta * mean1
correlation = covariance / sqrt(variance1) / sqrt(variance2)
return (correlation, alpha, beta)
</pre>

Incidentally if you are just starting out with Python you should look at NumPy instead of numarray, it is under active development and seems to be the future direction of array programming in Python.

http://www.scipy.org/NumPy

Martin

 

[nononsense]

Quote from Sparohok:


Something like numarray could be written in C++, and probably has been, but the Python object model and syntax make it particularly clean and expressive.
[]
Martin

If you look at the internal buildup of numpy and numarray, you will discover that a large part had been existing as C/C++ libraries and another part as Fortran libraries.
The writing of such a comprehensive mathematics package requires indeed many years, nay 10-20 years before it is sufficiently debugged and tested in order to become the reliable library as we know it today. It is the result of a major collaborative effort between many research organizations with many active individual participants.

The presence of Fortran may surprise the unfamiliar with scientific computation.

 

[Equalizer]

Quote from nononsense:

Let's all conclude then that "quants" doesn't mean anything, except for fuzzy dreaming about money-making. Another footnote for a future edition of "Extraordinary Popular Delusions and The Madness of Crowds".

Speak for yourself with regards to any such conclusions reached.

 

[andread]

Quote from Sparohok:

<i>You are talking about compiled Python, I assume.</i>

Nope. Good ol' Python interpreter. You don't seem to understand my point. Programs spend most of their time in small parts of the code (Amdahls law). If your program spends most of its time in the Python library (for example array operations) then you do not pay a significant penalty for running under an interpreter. In the example I gave the penalty is no more than 10%.

If your critical sections are interpreted, then the slowdown against a compiled language will be much higher, 5x or more. Of course you always have the option to rewrite your critical sections in C while retaining the advantages of Python for the bulk of your code.

aaah.. yes, that makes it a bit clearer. I don't know if it's possible to run so much code only in the library, and I don't know how fast the library is, but this sounds more realistic.
I also appreciate more the idea of Python interfacing with native code, although I would probably prefer in that case to use only one language.

Quote from Sparohok:


It certainly helps. I'd much rather maintain 50,000 lines of Python than the 200,000+ lines of C++ I'd need in it's place.
Martin

Yes, it does. I will trust you on your 4:1 proportion

Quote from Sparohok:


Since you claim Python is ill suited for large projects, can you explain why? Your personal aversion to dynamic typing doesn't seem sufficient to draw such a broad conclusion.
Martin

mmmm, I personally consider it an important factor. The thing i liked least in Java is the lack of templates, that forces me to cast every time a use a collection. I change the type of the collection, nothing checks my casts. I can imagine that in the case of Python this can happen much more often (in complex code, of course).
But, just to put something more, I might mention (please tell me if I'm wrong):
1) limited access control. Python has a kind of private access that is not really private, and it doesn't have protected or anything like that. Even the C++ friend (which sucks) is missing
2) no checked exceptions. Thrown exception are not checked. Not that C++ is better, to be honest (there are tools, though; maybe something similar exists for Python). I personally prefer the Java solution.
Lack of enums can also be a bit annoying. I did see some workarounds, but I'm not sure how effective they are.

I am also aware of some strange syntax constructs, but this is probably very subjective.

Maybe I should mention one last thing. I haven't developed C++ for a few years, but it's still my language of choice if I have to develop a stand alone (non web) application, and mainly for one reason: performance. As a language, I have to say that since 1.5 Java is starting to be quite appealing, although I would still like a couple of things more

 

[nbates]

Gotta say, It's pretty easy to separate the men from the boys in this thread.

I've coded under almost every ASM, C, Fortran, Pascal, Lisp, Python, Perl, Java, C++, C#, VB, .NET, and other languages in the fashion of the day (applications, device drivers, and firmware on all platforms)...and really need to say there is NOTHING that beats well architected C++ <<[template]>> code for applications.

If you want GUI use WTL and if you want Database, there are a ton of API's to chose from...I prefer Embedded databases myself, but in most circumstances just bypass that and implement my own home-grown variation (for speed), since all that SQL stuff is really just hash tables with pointers into memory mapped files.

The real payoff's though are when you start to take a system's approach to the problem(s) and, once you get away from the language or OS doing all the work for you (or so you think), realize the real benefit is finding a balance (the right one!) between CPU, I/O, network, data and code.

Not too many context switches or application driven hardware interrupts and knowing what parts of your software need to run and belong at the IPL Kernel level and which ones can and should run in User mode. Coalesce your data, it's movement and the GUI operations for maximum efficiency and minimum latency.

Then of course, there's a benefit in having the ability and/or capability to take things all the way back to the server and build your own Machine down-under, so those FAT Client applications can drop a few calories and your signals can drive trades the way you want them to.

I guess all that can be done in Python, Perl, CGI script or whatever (and yes, XML and COM are the answer! lol)...but, real programmers are not self-proclaimed, they just work and get the job done.

-rant-rant

 

[Sparohok]

Quote from nbates:

I've coded under almost every ASM, C, Fortran, Pascal, Lisp, Python, Perl, Java, C++, C#, VB, .NET, and other languages in the fashion of the day (applications, device drivers, and firmware on all platforms)...

but, real programmers are not self-proclaimed, they just work and get the job done.

Oooooooookay.

Martin

 

[TSGannGalt]

*yawn*

So what kind of tasks does the thread starter need to develop?

Picking a programming language depends on the requirements of the project.

I personally use C# because it's enough.

Can program in Java, Python, and a little C++ (really little...)