I wrote my first "basic" program on a DECwriter. That was back in the ... never mind. I guess I'm getting old too.
It was actually the vt220's we had at uni IIRC... not old enough to have used a DECwriter. You're getting really old. Was lucky enough to have one of these (either the 286e or 386s, if only I could remember that far back) in my dorm during the final years, connected via slip to some new fangled network (can't remember the name now, lol):
It was a good looking machine IMHO. But heavy, and used torx screws to get at the innards with those expensive proprietary drive bays (hated that)... pretty sure it was the 286e also. I can't imagine having had enough cash for the 386s. Still think I was pretty lucky though, it had a whole megabyte of RAM! ONE WHOLE MEGABYTE! Think of the possibilities.
IB had a good API, not used it in years myself as have switched to Rithmic as i trade futures and IB raised margins so high on intra day futures it was a joke. If it is stock trading you need to automate then have a look at the IB API.
The best way, IMO, is to code to a meta-API that can, transparently, connect to multiple other APIs, which makes it easy to switch brokers or data streams. Medved Trader, for example, is a PC application that connects to lots of brokers and data streams. It also has an internal simple Websocket API that will allow you to write your own code to trade through or monitor your accounts through any of the brokers it supports (and utilize most data sources it can connect to), as well as use its internal alerts/scanning functionality etc. Here is the doc: https://www.medvedtrader.com/wsapi
Same as my suggestion here: However, I think this often turns out to be "putting the cart before the horse". It's a good idea for systems programing. But, an application programmer IMHO, should simply choose the best API available and write against it. And, focus on keeping their internal application interfaces modular and clean. Your broker is your partner and it should be unlikely that you'll want to switch away. If push comes to shove, then you add the shim/compatibility layer when necessary. This way you get something usable first. Otherwise you end up trying to build the perfect [meta]API and procrastinating, i.e. bike-shedding. Building a shim or meta-API is slightly tedious but not rocket science by any means. And if you choose wisely to begin with the API will already be thought out by the vendor. You'll only have to swap a library file and maybe run sed or a macro on the header/source files to switch. Sometimes it's as easy as swapping a symbolic link, or adding a function into your shell. Here's one of my favorite completely over-simplified examples: Code: function stfu { nohup $@ &> /dev/null < /dev/null & } And, for the love of God, avoid #ifdef C macro style portability like the plague. At least that's how I see things, again from an application development perspective. Make sure to choose wisely in the beginning though... if you're that worried look toward some standard (e.g. the FIX protocol). P.S. No offense intended against your many years of Algol-68 experience
The one I suggested already exists and is being used by a lot of people. Well, to be fair, maybe 2 years' worth. Then I moved to a better country and used/programmed the (at the time revolutionary) PLATO system. Which was like moving to a different century.