The 1802 is clearly nicer to program
Are you kidding? It was "nicer to program" only in the sense the architecture was so weird that there were standard APIs developed to do the "unpleasant" stuff (like some sort of stack-based procedure call.) Sort of like writing in RISCy microcode, where each microcode instruction took 16 clocks.
I said it was slow :-)
But, yes, I stand by it looking more pleasant than the 6502 to program. Certainly it's not as nice as a modern processor, but it's not awful.
There's an 8 bit accumulator ("D") that all arithmetic goes through (as with 6502 and z80), and only via mem->acc operations (as with 6502). The memory operand can be an immediate or it can be the byte pointed to by any one of *sixteen* 16 bit pointer registers. Exactly which pointer register is not specified in the add/adc/sub/sbc/or/and/xor instruction itself, but by the most recent SEX (set X) instruction. You can also shift or rotate D by 1 bit position.
Any pointer register can be incremented or decremented as a 16 bit unit in a single instruction. You can load or store the byte pointed to by any pointer register (specified in the instruction) to/from D, with or without incrementing the pointer. You can push or pop D to the address in the pointer register set by the most recent SEX instruction. You can move either half of any pointer register to or from D, allowing you to use them as 32 8 bit registers.
Any pointer register can be the PC, using a SEP instruction. If a function uses a different PC register from its caller then it can return simply with an SEP with the caller's PC register. That's funky, but you can deal with it.
The conditional branching is reasonably sensible, with some flags and branch on zero/nonzero/negative/positive. The only weirdness is the branch specifies an absolute address within the same 256 byte page rather than a relative address. That's annoying, but don't PIC programmers get to deal with that too?
Suppose you have two 16 bit values in memory, pointed to by registers A and B on 1802 and by zero page addresses A,A+1 and B,B+1 on 6502, and you want to add A to B.
On 1802 I get:
SEX A
LDN B
ADD
STA B
INC A
INC B
LDN B
ADC
STA B
DEC A
DEC B
All are single byte instructions, so that's 11 bytes and I think 22 instruction cycles and 176 clock cycles, 50 us at typical clock speeds.
On 6502:
LDY #0
CLC
LDA (B),Y
ADC (A),Y
STA (B),Y
INY
LDA (B),Y
ADC (A),Y
STA (B),Y
That's 9 instructions, 16 bytes, and 36 clock cycles, 36 us at typical clock speeds.
That's a pretty similar amount of pain for both CPUs in this case. As I said before, the 1802 code is generally more compact, but the 6502 code will generally run faster.
The 6502 has more zero page locations available (256 bytes) than the 1802 has registers (16 registers containing 32 bytes), but it's rare for code to need more than 16 pointers.
As the examples get bigger, I think the ability to increment and decrement the 1802 registers independently will be a lot more convenient than everything sharing Y as the index on 6502. If you have to increment or decrement the actual pointers in 6502 zero page it starts to get quite painful, at least if there can be a page crossing -- then you need "INC A; BCC .+2; INC A+1" which gets both big and slow.
If I'm writing a compiler, I'll take the 1802 any day. And I think for assembly language programming too.