I'm not sure about Ocean, but a lot of companies used the Tatung Einstein, itself a 64KiB machine, as a development platform. I would assume that the software used for building this stuff was able to deal with source files larger than the machine can hold. They might've moved onto the likes of Atari STs, IBM-compatibles, and Amigas by the time Wizball was released though.
Plenty of music was developed in the form of source files.
From what I’ve read it was not at all uncommon to have a MS-DOS machine that assembled your code much faster and spat it into the c64 over a parallel link.
Some of the sound drivers would be paired with a machine code monitor, and therefore you could interactively develop by modifying hex bytes, which when you think about it, is basically the prototype for a tracker workflow.
There was definitely a tendency to do "compose on the piano, then arrange" with a lot of the early chiptune workflows though. With Galway's stuff there is more reliance on proceduralism to get those long evolving sequences, something which is actually easier to access when it's built from source files and you can define rhythms, chords, dynamics, modulation as forms of indirection.
Sound trackers actually originated on the C64! Chris Huelsbeck's Soundmonitor is generally regarded as the first tracker. There were plenty of others, such as Electrosound, Future Composer, Ubik's Music, and the Ariston Music Editor. It's not that nobody used software for this kind of thing, but it was pretty common to just use your own sound routine and toggle stuff in.
Plenty, but these days mostly if you either (a) want a simple implementation or (b) don't have to worry much about cache locality. The problem is that (b) doesn't really exist outside of retrocomputing and embedded systems these days. It's still one of my favourite data structures, just because it's a clever way to get most of the benefits of more complicated datastructures on small systems with minimal code.
Occasionally in pure python "asymptotically reasonable, simple implementation, terrible memory locality" is the right pick for a data structure. You want to avoid an extra linear term, you don't care too much about the constant factor, and the cache doesn't really matter because the language is so slow that it's not really noticeable.
It's a tool with a long vintage, and it wouldn't make sense to port it to a different language just to take advantage of the likes of bubbletea or textual.
The US is not in a position to process much of the sweet crude it has. Instead, imports sour crude, which is what much of the US's refineries are actually built to handle. This is why Venezuela was such a thorn in the side of the US, as they were one of the major producers and also largely produced sour crude.
As adwn says, it's a globally priced commodity, and the US is not in a position to disentangle itself from that market because in spite of being one of the world's largest producers, US refineries are not in a position to process that product, so it needs to go abroad. The US needs to import significant amounts of sour crude to be refined for their own use.
The US is just as screwed as the rest of us.
Also, the primary worry for Europe isn't oil, it's natural gas.
reply