Um, no. Maybe you do stuff like that. Most C64 devs used assemblers. We stored source on disk and ran assemblers on them.
For the first C64 game I wrote  I actually used the Atari Macro assembler since it was pretty well made and supported relatively large programs. Then I'd transfer the result over to the C64 by the joystick ports with some custom cables and software I wrote.
On the next big project we had dev environment that ran inside Super Text  on the Apple II and stored source on a networked Corvus HD. Pressing some combination of keys would start a compile directly from inside the editor. I don't remember how we transfer it. (getting old)
> Most C64 devs used assemblers. We stored source on disk and ran assemblers on them.
From my perspective, devs that were able to do that were extremely lucky. I gave up trying to program my (contemporaneous) ZX Spectrum in raw machine code with a tape deck for storage after one too many catastrophic failures, and I didn't take up programming again until ten years later when a friend donated me an old PC compatible.
Edit: And yes, I'm still kind of bitter.
For most kids, programming was BASIC, or BASIC combined with some assembly loaded as DATA blobs. The problem was getting an editor, monitor, source level debugger like for instance http://djupdal.org/cbm/64asm/ but there were things like The Final Cartridge. My dad used it to cheat at games but I found a lot of use to it.
The C128 integrated a memory monitor and disassembler. It was a lot easier to do something decent in C128 without proprietary tools. Sadly it never caught on. But even to develop for the C64 it was a great machine. For most kids it was a lot better to program-play. Like the Spectrum, it had graphic primitives in BASIC. Believe it or not, there was no graphics mode in the C64 that didn't involve playing with memory maps (for sprites) or assembly/machine code.
I didn't do much with the Speccy as I was a Commodore kid but I loved playing with its graphics in BASIC. I never got to do anything more sophisticated than that in that platform. I believe most pros back then did cross-compiling from 128K+ machines to the 48K or the Plus.
Now I collect all these machines but I haven't taken the time to go back and see how would I do things now. There's a lot of stuff I didn't know back then, for instance Forth, which would have worked a lot better besides "machine code" than BASIC.
What I find most amazing is that I remember all this stuff with precision (I can still remember POKE codes) and I barely remember anything else from these years. I have vague memories from even friends, teachers, cartoons...
I have to admit, Microsoft got a lot of stuff right with the QBasic that was bundled with MS-DOS. Hitting F1 would bring up an amazing help system that documented various features of the language with code snippets. I remember discovering the "DRAW" command, and how much fun I had with it. I came across it on the documentation; and the code snippet is what made it really easy to learn how to use it. But the doc was well-written too -- sufficiently simple for an 8-year-old whose native language is not English, to understand.
Now imagine that I had some *nix -- vi/emaccs alone would put me off, erm, any text editing, not to mention programming. Also, just the way Unix is, where things often break silently, and the system assumes you know what you're doing -- just isn't suited to an 8-year old.
I'm kind-of disappointed at the state of programming right now. Many of the popular languages of today -- JS, Java, Obj-C, C++, etc. are no where as simple as the BASIC dialects are. Python though, is actually a good candidate. With a nice Turtle-like library, it would be a perfect beginner's intro language to programming!
I'm sure some people tried to get along with raw machine code, but I doubt that many did.
I would agree that getting microdrives did make a huge difference, but even when I was still on tape it was a hell of a lot easier for me to do that than keying in hex values.
While I had to type everything by hand on the same computer, most companies (well game studios) were using those type of solutions.
With which I wrote several programs during my high school years. The thing that sucked about the Atari Assembler Editor is it worked like basic. Lines were numbered. You'd type LIST to see your program each line prefixed by a number. LIST 100-200 would list lines 100 to 200. Etc.. But you could renumber lines to insert stuff if you ran out of line numbers.
That was replaced by the Atari Macro Assembler.
Which I also had in my high school years before going pro. It was pretty similar to modern assemblers.
I don't remember the price but I wasn't rich so it couldn't have been that expensive. It's possible I pirated the Atari Macro Assembler (thought I don't think so) but I couldn't have pirated the Atari Assembler Editor Cartridge :-)
Many Pros used more powerfull systems and downloaded the code via the extension interface.
I wrote many intros using the Power Cartridge monitor, before I learned about assemblers. For small projects it's fine!
So if you had a game where you moved a little character around the screen with the joystick, and you neglected to handle the case where he went off the screen to the top or bottom, you could crash him right into your source code (which was being actively interpreted).
It'd dump you out abruptly, you'd list your program and find that a section had been monched and now contained a bunch of random special characters. Ouch.
That hardly ever happens to me anymore, writing front-end code for the browser. But still I make a point of checking my bounds, just in case!
I know this because a colleague in the office is still active in the demo-scene (yes, it's still active) and participates each year in competitions.
I do wonder why he is using a tape drive, though. That is taking retrocomputing a step too far. We had a 1541 (IIRC) from day 1 when I first got the C64 back in 1983, four years before the author was born. Tape is too painful; and should be reserved for someone who wants to retrocompute on the VIC-20.
I was trying to explain how delightfully 'tangible' the C64 was the other day - POKE something into memory and bang, stuff happens. It never ceased to amaze me how much improvement could be achieved over the baseline h/w and s/w setup too - order of magnitude faster disk access, 80 columns, etc. etc.
It was honestly pretty amazing stuff looking back on it 30 years later and likely what got me in the field.
I kept a lot of his C64 books and magazines after he passed away a few years ago, I might try and scan them or go through them myself one day.
Don't miss the .png at the end that has the entire source code with explanatory annotations!
You mean I have to type it in by hand?
In the final graphic he says it took him only 8 hours though.