As someone who started out in assembly, I would say you’ve made some shockingly bold — and painfully unfounded — statements. In fact — to be brutally frank — it sounds like you’re talking out your backside.
This is a fairly known concept that the number of bugs in a program is proportionately correlated to the number of
gotostatements in it.
Are nonsensical in how few people use “goto” anymore, how many languages lack it right now, how “goto” now points at labels in the languages which do support it having clear meanings and are easier to search for, that once compiled ALL code logic relies on jump, jump conditional, or call. ALL of which are basically the equivalent of “goto”. Much less functions that rely on “call” meaning they are kissing cousins to “goto”.
I guess it’s like the nonsense we’re hearing from “functional programming” whackjobs where they rant and rave about “teh evuls f teh loopsies” as they call functions and object methods that internally are actually looping, meaning ALL they’ve done is add the unnecessary overhead of function calls (in the form of callbacks) to each blasted loop. 100% hurr-durrz.
But if we follow the process of a debugger we see that there is a time element that morphs the parameters of function execution. This is particularly horrible in code with
gotostatements. The code starts to hop around.
What the devil does that even mean? Whist there are plenty of arguments against “jumps” when there are alternatives — and let’s call them what they are, JUMPS not “goto” — execution time is rarely one of them since under the hood ALL of them are some form of jump, jump conditional, or call which is basically a stack push of the current program counter and a jump. (where the “return” is basically a pop of the PC)
Take this pedantic nonsense:
Ideally, a function should do one thing, in a testable manner. If a function has an else statement in it, it is now by definition not doing one thing, it is doing something else. Get it?
Nope, that’s the type of “career educator” BS I’ve heard thousands of times for near-on four decades, and it’s the same narrow, short-sighted, ignorant trash it was when I first heard it in my teens in the early ‘80’s. Somewhere, at some time, you are probably going to have to do a conditional. Functions exist to DRY, so if you’re repeating that condition why not put it in the function? The alternatives are often more code, harder to follow, and execute many times slower since functions/methods involve a great deal of overhead. Again, to go back to machine language terms — assuming a compiled language — it’s a push of the PC, push of arguments, write of the PC to the function address, allocation on the stack for locals, running the actually code being called, resetting the stack pointer to de-allocate locals and parameters, then popping the PC (ret).
Seriously, something simple like this:
; BX, DX
; AX = video card detected, see videoCard_ defines mov ax, 0x1200
mov bl, 0x32 ; VGA only enable video
cmp al, 0x12 ; VGA returns 0x12, all others leave it unmodified!
jne .notVGA ; not a vga, test for EGA
; VGA, or is it? test for MCGA
xor bl, bl ; null BL so it's set up for non-PS/2
mov ax, 0x1A00
cmp bl, 0x0A ; MCGA returns 0x0A..0x0C
cmp bl, 0x0C
mov ax, videoCard_mcga
mov ax, videoCard_vga
ret.notVGA: ; We eliminated VGA, so an EGA/VGA true must be EGA
mov ah, 0x12
mov bl, 0x10 ; EGA/VGA get configuration info
and bl, 0x03 ; EGA/VGA returns a 0..3 value here
jz .notEGA ; not a EGA, test for MDA
mov ax, videoCard_ega
ret.notEGA: ; MDA all we need to detect is video mode 7
mov ah, 0x0F ; get Video mode
cmp al, 0x07
mov ax, videoCard_mda
ret.notMDA: ; not MDA, check for Jr.
mov ax, 0xF000
mov ds, ax
cmp [0xFFFE], BYTE 0xFD
mov ax, videoCard_pcJr
ret.notJr: ; not junior, test for tandy
cmp [0xFFFE], BYTE 0xFF
cmp [0xC000], BYTE 0x21
mov ah, 0xC0 ; test for SL/TL
int 0x15 ; Get System Environment
jnc .tandySLTL ; early Tandy leaves carry set, TL/SL doesn't
mov ax, videoCard_tandy1000
mov ax, videoCard_tandySLTL
mov ax, videoCard_cga ; all other cards eliminated, must be CGA
Must absolutely horrify and terrify developers like yourself given the number of needed and important conditional jumps. Basically the equivalent of “if (x) goto y”. Probably also scare the “no side effects” nitwits and other such know-nothings who seem bound and determined to make programming as difficult as humanly possible.
Overall your article makes a lot of claims, but is based in vagaries, card-stacking, and is devoid of legitimate “A vs. B” examples to support your statements.
I think that high level languages are starting to reach the point where people are so ignorant of the bare metal, they’re making stupid inefficient choices that make everything harder, more code, and based entirely in ignorant nonsensical choices.