No I wasn't kidding, and I was just saying ASM is easier to understand - I said it was harder to work with, which is basically what you're saying, so we both agree. I never said ASM was elegant, either.
I didn't say you say asm was elegant either
Overloading - can be your "fault" (using your own term), but it might more likely be the "fault" of the library you're using because either 1) everyone uses this library and 2) this is the standard way of doing it and your language doesn't offer any alternatives.
If you use a library without having the slightest insight of how it works, then this is your "fault" (using my own term). Note that my exact saying was "the fault of the programmer", not "yours". After all, ther's a programmer behind a library.
Just ask a random OOP programmer how complex is string concatenation with "+". Nobody even thinks that this will allocate memory for a new String object concatenating both strings and so on, unless explicitly asked.
I agree with you on the fact that many bad programmers use high level languages (especially C++).
I agree too on the fact that any coder should have a deep understanding of low/mid level languages (asm and C) because at this level, you must understand how things works at the memory level, and why copying strings is usually bad. Many coders lack of knowledge in algorithms too.
I think our agreement comes from the definition of what is "understood":
that's why I asked you earlier to clarify this word.
You're telling me that an algorithm written in high level is easier to understand, which is true, and I'm telling you individual instructions in ASM are easier to understand.
Honestly, I don't think. There are many instructions for similar tasks (in 68000 : move, movea, lea,...). More, they often have different little-known side-effects (on the CCR for example) whereas their main effects are similar (again, 68000 ; there's an article on the subject on Easy68K website). More, their names are cryptic.
Most high-level languages have very few instructions, and the most used are easy to understand.
Let's try python : the most common instructions are print, for, def, arithmetics and logics (with quite widespread notations). I think most coders (even bad) understands what they mean.
EDIT : I saw you mentionned MIPS, and I'd say that it's a great exemple : MIPS instructions are even simpler than say 6502 instructions, as there is no status flags, multiple adressing modes or register non-orthogonality, so this makes MIPS instructions simpler to understand. However, a MIPS assembly program would be even harder to understand, because more instructions should be used in a more tricky way to get the work done.
Damn delay slot !!!
Nonetheless, I studied and modified codes mainly on PS2/PSP (MIPS) and Genesis (68000) and I didn't find one easier than the other excepted on the fact that good debuggers exist for Genesis, and none for PS2/PSP, to my knowledge)
Basically programming is a trade-off between simplicity of the individual instructions, and simplicity of the whole programs. Assembly goes for the former, high level OOP for the later.
I think by 'simplicity of individual instructions', you speak as if you were a processor
And I get your point. But for a human, I think that's not the only point of view. CaML again has very few instructions (to the least, I use really very few), they are very simple, and it forces you to think in such a different way... BTW, you're forced to understand why string concatenation is bad with it too !
Nonetheless I doubt anyone would use asm because instructions are simple (or else beginners would start with asm, which is rare), but because it's fast (provided you wrote an efficient algorithm).