I would suggest respectfully to read a bit about Python. It may help.
Come back if you still have any questions left.
best language for quantiative finance? C, D, Fortran,python etc.
- Thread starter Batman28
- Start date
Come back if you still have any questions left.
Only trying to help fighting ignorance.
If you have any historical sense, you might reflect on IBM's PL/1 and the difficulty of getting that omnipresent & revered dog out of the woodwork, especially in academic environments.
ya must be a guru
Quote from nononsense:
ya must be a guru
Not really. I used to be into development the same way many people here are into trading. Just enjoyed it. That's why I have "strong opinions". I always try to avoid arguments, though. Not always successful
I would like to be one day able to discuss about trading in the same way.
Lots of books to read...
<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.
<i>I can imagine that Python does more per line of code (and how much more?)</i>
It depends on what you're trying to do. I'd say Python code is between 2 and 5 times more compact than C code.
<i>but that doesn't make it suited to large project development.</i>
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.
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
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.
<i>I can imagine that Python does more per line of code (and how much more?)</i>
It depends on what you're trying to do. I'd say Python code is between 2 and 5 times more compact than C code.
<i>but that doesn't make it suited to large project development.</i>
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.
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
I personally prefer C++ over all other languages. I donât really understand when people say it is harder, unproductive or even bloated.
If your C++ code is slow, bloated or took too long to develop it is because you need to improve a C++ skills a little bit. When it comes down to it, just like with any language, it is all about how deep your understanding of what is going on under the hood is and how you can make the best of it.
And in the end, being it good or bad, C/C++ is still the 'dollar' of programming languages and I am not sure if I would invest time on any other language right now - even if it is in theory 'better' than C++.
When I look around, I see that pretty much everything is a product of C/C++ in a way or another and while a suitable 'successor' isnât appointed, I am going to stick to it.
If tomorrow by any reason I have to write something in Java, Python or even Visual Basic, I sure would - why not? The individual successes of these languages are a testament of their qualities - they wouldnât be so popular if they weren't good enough to thrive in a world where new programming languages are created and forsaken every day.
If your C++ code is slow, bloated or took too long to develop it is because you need to improve a C++ skills a little bit. When it comes down to it, just like with any language, it is all about how deep your understanding of what is going on under the hood is and how you can make the best of it.
And in the end, being it good or bad, C/C++ is still the 'dollar' of programming languages and I am not sure if I would invest time on any other language right now - even if it is in theory 'better' than C++.
When I look around, I see that pretty much everything is a product of C/C++ in a way or another and while a suitable 'successor' isnât appointed, I am going to stick to it.
If tomorrow by any reason I have to write something in Java, Python or even Visual Basic, I sure would - why not? The individual successes of these languages are a testament of their qualities - they wouldnât be so popular if they weren't good enough to thrive in a world where new programming languages are created and forsaken every day.
Indeed, C++ is the best. That's why Python stuck VERY CLOSE to it. If you don't know any better, by all means use C/C++. If you know better, use both but only C/C++ when you really have to (almost never).