More Bullcookies and Balderdash
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.
Statements like:
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)
Certainly, overdoing it with “goto” can lead to the feeling of spaghetti code, so can derping in functions for nothing (Encouraged by the dumbass arrow function trash), object methods with callbacks (like JavaScript’s derpy “Array.forEach”) and a host of other painfully inefficient and bloated code methodology. Made all the more of a tragic comedy by how many of the people advocating said techniques run their mouths about “spaghetti code” whilst clearly having no idea what that is much less ever having dealt with it.
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).
… and that’s in a COMPILED language, don’t get me started about the **** show modern interpreted languages like JavaScript are where they basically do locals on the heap so they can have hoisting and persistence; thus the S***-show that is “garbage collection”. The function overhead becomes as much of a disaster as how such languages PRETEND to have Arrays.
Seriously, something simple like this:
detectCard:
; ACCEPTS
; nothing
; CORRUPTS
; BX, DX
; RETURNS
; AX = video card detected, see videoCard_ defines mov ax, 0x1200
mov bl, 0x32 ; VGA only enable video
int 0x10
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
int 0x10
cmp bl, 0x0A ; MCGA returns 0x0A..0x0C
jb .isVGA
cmp bl, 0x0C
ja .isVGA
mov ax, videoCard_mcga
ret.isVGA:
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
int 0x10
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
int 0x10
cmp al, 0x07
jne .notMDA
mov ax, videoCard_mda
ret.notMDA: ; not MDA, check for Jr.
push ds
mov ax, 0xF000
mov ds, ax
cmp [0xFFFE], BYTE 0xFD
jne .notJr
pop ds
mov ax, videoCard_pcJr
ret.notJr: ; not junior, test for tandy
cmp [0xFFFE], BYTE 0xFF
jne .notTandy
cmp [0xC000], BYTE 0x21
jne .notTandy
pop ds
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
ret.tandySLTL:
mov ax, videoCard_tandySLTL
ret.notTandy:
pop ds
mov ax, videoCard_cga ; all other cards eliminated, must be CGA
ret
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.