(this is part 6 of the Algo-Trading Journey series)
The biggest red flag 🚩 in a language is when you can't use it to do what you want, and you absolutely MUST use external libraries (written in different languages).
Popular Deception
This reminds me of a joke where one fish asks another, "How's water?" 🐟 🐠 and the other responds, "What is water?" 😅
The point is that when something is so prevalent and all around you, it's actually hard to see it. Or even notice it.
The same is true for languages like Python when it comes to data science.
It is the most popular language, and everyone just assumes you need to use libraries like numpy or pandas.
But no one stops for one single second and asks... why?
LEARNING CURVE
How much easier (and simpler) would it be if you could just loop through the data using the for loop?
But you can't do that in Python because it's 80x slower than compiled languages (or some crazy big number like that).
On the other hand, compiled languages are very fast but also very "brittle".
Everything needs to be very precisely defined, and they're (usually) not very good for prototyping.
SIMPLE AS PYTHON, FAST AS C/C++
As impossible as this task seemed to be... after I spent a decade in software development, I managed to find a language that is:
- (extremely) easy to learn
- simple as Python
- fast as C/C++
- is compiled
- but can run as a script
- stood the test of time (not new at all)
- and is overall the biggest undiscovered gem!
Here, you can download a full report on The Best Programming Language For Finance.
Beware of the Demo
This is how they hook you.
It works (quite literally) the same as fishing bait. It looks good until you take a bite... and then... there's no going back. 😲
Popularity is based on the greatest building speed when going from scratch.
BUT... this scenario covers only 0.1% of the entire lifetime of the project
... (maybe even less).
That's why I choose to focus on the productivity that impacts the rest 99.9% of the project.
FALSE PRODUCTIVITY ASSUMPTIONS
When you see a small part of the project built quickly, you immediately assume the entire project will be built faster.
And this couldn't be further from the truth.
That's why frameworks are popular.
You're sold on the idea you can do 90% of what you need in a fraction of the time...
...but then you pay for the rest of the 10% in full (and with interest).
And over the entire lifetime of the project, you end up spending 200-300% more time "coercing" the framework to do what you want it to do.
When in reality, you could have just not used the framework at all and gotten 2-3x more long-term productivity.
(this is a very steep price to pay for the first month of productivity euphoria)
Holistic Approach
Using the same language for prototyping and production reduces context switching.
Being able to do the data manipulation with the language itself (without external libraries) is incredibly refreshing and productive.
(not to mention, you don't have to learn all those extra frameworks)
Having the language be able to switch between being very type strict and very relaxed is powerful.
Even more powerful is the ability to work as a high-level language, but also having an option to switch to low assembly-level control (with a single line of code).
auto arr = [1, 2, 3, 4, 5, 6, 7, 8, 9];
auto evenArr = arr.filter!(x => x % 2 == 0);
👆 Looks almost like JavaScript (but it's not)... and it looks so simple and intuitive... and yet... it runs at near-C speed. 🤯
Now, THAT is the stuff a good programming language for finance (and anything else for that matter) is made of.
🎤 #micdrop
What's Next?
I plan to post my progress here on dev.to because I find it fun... and I enjoy it.
If you want to join me on this journey, then I suggest you:
- follow my profile for more updates
- bookmark this article for future reference
- and like this post, so more people can see it
Now let's go and conquer the market :)
Will
P.S. here are some cool resources:
1. Best Programming Language For Finance
2. (FREE) AI For Finance Tutorial
3. Starter Code For Bot Building
Top comments (0)