I've been developing my own app to execute my own algorithm. Since i was familiar with VBA prior to this, i prototyped a lot of tests and proof-of-concept in VBA. Then came time to pick a platform, and a language, to build the app that actually executes through the various exchanges i want to work with. So I've looked into Visual Studio Code, and Visual Studio 2022, settling on Visual Studio 2022 free version. On that platform I've looked into C# and of course Visual Basic. C# offers the most open-source libraries for trading, so that is the logical direction to go. For example, there is a lot of open-source websockets code available through either GitHub and/or NuGet, an easily accessible library facility through Visual Studio. So the logical step would have been to skip Visual Basic, and begin to transfer coding skills over to C#. Along with this, the logical next step would be to employ a "console" app, the easiest/fastest way to get an app up and running. So i began to consume some excellent C# courses available on YouTube. But then i realized that i would probably not be in need of websockets for a while, since my algorithm would not be able to overcome trading fees for the short time frames, without extensive use of limit orders and a ton of code that i would need to make that work. Instead, i thought i might just use market orders on longer time frames, and the REST API that are available from pretty much any exchange/broker. At the same time, i realized that VBA, in Excel, can be transformed into a console app. Did you know, for example, that you can type in the name of any Sub routine into the "Immediate" window, and have it executed? Yes, and you can even include parameters (arguments) in those calls. Of course, then you can output anything you want to see into the same Immediate window. That, basically, is a console app. So, since i had already, painstakingly, found and adapted some REST API code for VBA, i decided to just keep going with VBA for a while longer before making the big switch up to C# on Visual Studio. My big problem was that it is very difficult to find and adapt any websocket code for VBA. That is what almost pushed me to switch platforms. But now that my demands are not so heavy, i feel i can turn Excel into a fully automated console app. With REST API, about all you can demand, is data updates about every one minute. You can certainly explore the shortest limits, but that is what i decided is all i need for the longer time frames that i would be using, combined with market orders. A market order means you can register your order on your exchanges server, ready to go, if price ever crosses your threshold. This way, you don't need to be watching price every split second through websockets like you would if you were using limit orders. The key to an app like this is the Application.OnTime function, which will call the entry point of your program on any time schedule you want, down to every second. Of course, i am calling the entry point of my app every minute. In between calls, the program is totally not running, as if it was totally finished. This means there are no variables in memory, which is completely wiped out. This means that to maintain state, you have to write to file, and read from file, every minute that the application gets called. The other key to a console app is to have lists of menus (commands) that you make available for yourself, whatever it is you want to control from a command line. So that starts with usage lists that help remind you how to use your own functions, which get harder and harder to remember, the bigger and more complex your program becomes. Here is an example of three of my main usage lists:
You are going at this completely the wrong way. If you wanted to use excel for anything trading related then you can now use Python directly within excel.
I'm very aware of that. I chose not to go that route as well. And that route is still open, even with a finished VBA app since the concepts are similar: REST API, classes, time loop, dictionary's, collections, arrays, loops, read, write, splitting strings, and what have you. Then speed. Python is not known as a race track though it might (don't know) be faster than VBA. If speed is needed, it's easier to upgrade CPU and drive and RAM power than to come up to speed learning a new language. If Python would make it easier to implement Websockets that would be a time to consider integration, otherwise I would choose Python and/or C# (console ) on the Visual Studio IDE. Maybe Python could help with charting? That is all I'm using Excel for anymore. The editor will allow both languages in one program .
You do have the option to create console apps within Visual Studio without using Excel at all. Forget about Excel. You will thank yourself later down the line. Also forget about VBA and migrate everything to C#. There isn't a language as powerful as C#. It can even compete with c++ on performance.
In Windows and Linux (I think), you also have the option of Powershell scripts. I use Powershell for simple scripts for downloading data, but for trading applications, C# is what I use.
Agreed they, and that IDE, and the libraries available from there, are powerful. Probably speed too especially if you consider multithreading. Not to mention much more info about how to implement a trading robot, if not rich libraries that almost represent a full implementation. I was considering that, and experimenting with it, at a time I was stuck trying to implement Websockets, but having already implemented REST API. And no doubt will get there. I started with YouTube "C#" in 8 hours type of courses and was on my way with Visual Studio, had gotten started with console apps, browsing Nuget, and had even used it to make a basic Add-In that sits in the Excel ribbon. So yah, even Visual Basic .Net in Visual Studio dominates Excel like a toy. But I was over the hump with the REST API and am racing toward the finish line, that being a working application on AWS running 24/7. In this way the idea is to earn while I learn (other languages platform) in an attempt to better the program over a longer horizon. I saw that I am not an expert or any kind of master in VBA and that I would bring my my own organizational problems to a new language, dragging that language down to my level, only occasionally pulling me up. I sometimes feel I am days away from a profitable implementation, but which stretch into weeks more, because of me, not so much VBA. So it was a tough choice, and partly because I was determined to master VBA enough to make a basic implementation, and not be defeated by it. I really like the editor and the intellisense (especially when working with classes) though we all know how intelligent Visual Studio is...almost too verbose for amateurs. I have my workbook open directly to the editor, and to the module/function I'm working on, and the sub I'm working on written into the Immediate window (console) already. Scaling for example, regardless the language, you've got to be on top of your game to scale to multiple positions on multiple exchanges. That's just plain hard work. Oh yah, Excel formulas have long since been deprecated along with cells and ranges, but Ive been over the hump with chart implementation enough to value the app just for that. The work i'm doing to implement a console type app is the same work, same kind of work, i would have to be doing in Visual Studio console applications.
I highly doubt you were aware of the python integration. It's very new and anyone who uses VBA for new projects today clearly shows he does not know better. Your comments on python are complete nonsense. Many python libraries are as fast as C++ because they were written in C++ with Python wrapper. Easier to upgrade hardware to make something faster than learning Python? Omg. Using excel for charting? Dump excel man. You are a nutcase who seems to love to torture himself. Your entire post makes zero sense and only shows you have zero clue what you are doing. I have written entire trading architectures, order management systems, matching engines, algorithm plugins, data pipelines, broker connectors/plugins for over 15 years in C#, C++, and Python. Let me tell you that the way you describe your integration is an amateurish, highly risky, and shaky way of writing an engine that supposedly manages live funding. But you seem too arrogant to even be willing to listen. Show me a broker that would suit a guy like you that requires web sockets or even fix connectors. On your level you are required to fit to given interfaces provided by brokers like IB which does not require websockets at all. They provide ready interfaces/apis in multiple languages. I spoke with another guy on this forum a while ago. He had a solid developer background but was extremely stubborn on wanting to integrate things the way he saw fit. He had zero finance and trading background. Thought he can score big because an over fitted strategy looked promising. His endeavour totally fizzled out and he is apparently back at being a coding monkey, occasionally doing consulting/integratuon gigs to help some onboard with a popular off the shelf backtesting and trading platform. I chatted with him privately for a short time but left after I figured out he was very poor at taking criticism or advice in areas he had zero clue about. Why I tell this story? Because I have seen tons of guys like you. Big ass dreams, but taking shortcuts to cover the areas they have no domain knowledge of and arrogantly refuse advise from those who have run this kind of business for decades. A lot of IT guys among them surprisingly (I expect better from engineers). Most always they fail.
My review of how Python is implemented in the Excel/VBA editor was a long time ago (it's not THAT new), prior to my review of Visual Studio Code, Visual Studio, as well Python, Visual Basic, and C# on that platform. I drew the conclusion that Python, implemented in the VBA editor, was not going to help me. If you are sure of that, explain how you think it would help. Right now, the author of Python is working on a new version, absolutely trying to speed it up because people, in general, would like to see it faster. I don't know how it compares to VBA but i'm liking the speed i currently have, even with older hardware, to fetch data, look at it, and come to a conclusion. My type of trading is not latency critical. Not right now. I'm surprised you think that the 40% increase in speed one might get from a language, can beat the 100% one can get by upgrading hardware. The best help is in open source libraries and code samples. If you think there are trading oriented libraries that can easily be incorporated with VBA then speak. And there is the issue of the time needed to migrate one's skills and code base.
https://techcommunity.microsoft.com...ning-the-power-of-python-and-the/ba-p/3893439 BS, it's brand new, not even in the release, it's in preview. You don't integrate Python in a VBA script. Dump the entire stupid idea of using Excel and VBA for what you aim at doing. It will never work. PS. What you refer to what is being considered re Python is the removal of the global interpreter lock (Gil). But that's a separate point altogether. Stop even ever dreaming about multithreaded or async applications if you don't understand why VBA is utter garbage in 2023. And my entire point was not on speed at all, you did not read carefully. My entire point is on your poor choice of integration tools/languages/libraries.
There are YouTube vids on the subject two years old. This one is one year old, which i reviewed a year ago: I'm not trying (anymore) to implement Websockets in VBA. But any REST API is totally doable so i'm not sure why you think it can't be done. I'm aware this is somewhat political. Someone wrote a library to help entice everyone away from Microsoft. But the enticement needed to be more clear than it was to me a year ago.