[vcf-midatlantic] assembler is tedious (was WooHoo!) (Jeffrey Jonas)

[Herb Johnson]

There's some irony in discussing the tedium of assembly language 
programming, by using (excuse me) the tedium of emails as a learning and 
describing tool. It's my bias, but the hardest way to learn something, 
is by having several people explain it, post streams of details, argue 
amongst each other in the process, get sidetracked, etc. I understand, 
that's the 21st century way; no insult, it's just not my 20th century 
way (or my textbook way, I was formally educated in computing).

Look. The vintage basis for assembly-language programming, included the 
limited resources available to microprocessor owners in the 1970's. 
Hand-assembly and front panels, limited memory, limited I/O, limited 
storage. Limited access to prior source-code. The other limitation was 
the owner him/herself: programming was likely a mystery, at least 
programming that particular processor, and later in time the mystery of 
whatever "system" architecture in use.

Results matter. Those owners learned, became computing experts, who 
became employed in the personal-computer boom to come.

So - that old-school way, mattered then; and matters now as a matter of 
historic preservation. So why preserve it? To remember the lessons of 
the 20th century past: a past of limited resources, versus the 21st 
century experiences of ABUNDANT, STANDARDIZED computing.

And so, calling assembly language programming "tedious" misses these 
points, imposes those 21st century assumptions on 20th century tech.

This is not some old man's problem with the future. My vintage Web site, 
attracts people who ask me "I wanna start with some vintage computing; 
where do I learn, how to program and repair these things?" I'm stumped - 
modern resources have mostly given up "assembly language" and "TTL 
logic" or even "read this schematic"!

If the above is too "tedious", if you are messing with vintage computers 
"for fun", and don't care about historic perspective, that's fine. But 
you have a choice. Try to sledge-hammer C code (or some 
language-of-the-year) from a cross-compiler into an Apple II, and trip 
over all the I/O it needs to "know"? Or, work within the Apple II's 
BASIC, Sweet-16, and assembly-language calls (documented long ago) - in 
assembler (readily accessible) - and get something DONE? And learn 
something "old"?

If you are worried about looking trivial - buy a Raspberry Pi and 
*guarantee* your results are trivial, just in a larger social group.

Harumph,
Herb Johnson



-- 
Herbert R. Johnson, New Jersey in the USA
http://www.retrotechnology.com OR .net
preserve, recover, restore 1970's computing
email: hjohnson AT retrotechnology DOT com
or try later herbjohnson AT retrotechnology DOT info