At most they would have to learn a new lexicon of programming languages and operating systems which are FAR less complicated than the current range of languages and design patterns software engineers must master today.
A few weeks (days?) of studying and figuring out how to pre-optimize for much smaller workloads and they'd be able to keep pace easily.
Yes, you would manage so long as you can handle a shell prompt and can grok simple assembler.
Today, you just focus on the problem and take the underlying platform for granted. Free Software has liberated computing from vendor-reliance.
Whereas today we have Android.
Perhaps cheating, since I started programming in that era, but I'm sure I'm not the only one that still has remembers assembly language techniques (if not even the mnemonics for one or more 8 bit chips), as well as remembering at least a handful of BASIC dialects, the finer points of bumming cycles and bytes to fit in tight spaces, etc.
In fact, though I certainly don't want to give up my curent tech, my primary emotion looking at those pictures was wistful nostalgia.
Maybe because computers were not so complex yet so you could actually fit their basic operation/commands in a few hundred pages.
Think about developing for Arduino with software running on an Arduino.
Imagine spending long hours trying to fit your code into 128k?
Mostly you'd be up against:
- No Intenet to look up reference material. For that you have books. I'm not sure how much of a revolution the online Unix man pages were, but I'd not worked on any other system that had that kind of documentation. Hope you have lots of bookshelf space (I did :-) ).
- No GUIs anywhere. There was Emacs, kind of. Mostly you got along with ed and regexprs.
- Frustrating toolchains; pre-ANSI C, with 7 characters of significant symbols on earlier systems. I don't remember if any Unix debuggers had symbol information, but they were all command-line driven at the assembly level, with no source information. That's okay, you could pretty much tell where you were by the assembly, because the optimizers were terrible.
- Email? Hoo boy. Might as well just go across the hall to talk to somebody, because unless you were on ARPANET that's about all the farther your email would get.
It'd be frustrating, but kind of fun.
Nice things:
- Tinier software. You've got skillz dealing with hundred thousand line programs. Things were smaller back then, mostly.
- No security worries. I don't know whether to laugh or cry, but DES was pretty controversial (the whole 56-bit key thing) and US citizens couldn't say anything to foreigners about crypto. No network, no crypto, right? (Unix passwords were encrypted with a rotor engine similar, and I think that salts came later).
- Boot times are about the same then as now. :-)
Heh. Heh heh.
As if.
Try less than 16k. Less than 8k in may cases. Certainly well less than 64k.
Oh, and it was an absolute blast fitting code into that space.
In fact, my first computer of my very own was a 1802 based single board I wire-wrapped my self. I had loads of fun coding up programs in the 1K of RAM I had at first.
And besides, there are people who enjoy it: the entire 64k and 4k demoscene categories live because it's an interesting challenge.
I'd write a cross-assembler that ran on the PDP-10. That's probably what Microsoft did, as I find it hard to believe that MASM 1.0 could have been used to compile DOS.
I'd also write the DOS clone in C, running it on the 10 with an emulator. Then I'd hand-translate it to assembler.
Remember, DOS 1.0 fit on a 160K floppy, including the numerous utilities thrown in. That isn't much code, even assembler code.
The thing about cross-development on a mini or mainframe that killed you was the download time. I did cross-assembly at Atari, and it was always the download time that took soooo longggg. Wrote a few smart downloaders while I was waiting for dumber ones to finish. 9600 baud sucks hard.