3 ms·

> stubbornly-held strong opinions many JS devs have ... a problem among a lot technologists in general Hmmmm... well, I might agree, but that would depend on t

> stubbornly-held strong opinions many JS devs have ... a problem among a lot technologists in general Hmmmm... well, I might agree, but that would depend on the opinion. There was a time when all programming was done using GOTO as the sole flow-control mechanism until a guy with a stubbornly-held strong opinion named Djikstra taught us that GOTO was considered harmful. Yet it's also the most natural way to code: a lot of people argued with him (in fact, the reason beginners don't use GOTO any more is just because it's not there, not because they've gotten more sophisticated). It's also a stubbornly-held strong opinion among many, but too few, developers, that global variables are also harmful. Unfortunately they're also the simplest, most obvious way to code, so a lot of developers default to using them. If a developer has a stubbornly-held strong opinion, I usually give them the benefit of the doubt to try to figure out why: often they have a good reason. (On the other hand, sometimes the reason is, "it's easiest", like using public static variables in Java).

game_the0ry 6y ago
Agreed. Well-reasoned stubborn opinions that are fleshed out through critical thinking are examples of good opinions. The stubborn opinions from fads, not so much. Those opinions try to signal - 'I am the smartest because I know the latest and greatest.'
jacoblambda 6y ago
The GOTO topic is an interesting one because Dijkstra inadvertently started a cult around the avoidance of GOTO. Dijkstra never intended this and one of the main reasons this occurred was because Dijkstra's original paper "A Case Against the Goto Statement" was editorialised as a letter to the author type article to speed up publication which resulted in the famous title "Goto Statement Considered Harmful". This is a topic where both him and other prominent figures such as Donald Knuth have since its publication repeatedly argued for moderation in use of the GOTO statement and against the total avoidance of GOTOs. My go to example for this is that in C and other languages that lack modern comforts such as exceptions(for better or worse) and destructors, GOTOs can largely simplify the handling of clean-up and error recovery code. Another example is longjmp which is very useful in kernel-space or bare metal programming, and in implementation details for exception handling however outside of those niches, serves no purpose. GOTO serves a very useful niche but can also make code nigh impossible to follow. Most other structured programming statements have the same threat but we have rules in place to avoid their abuse. The following cases can result in code that is just as problematic: IF/ELSEIF/ELSE: overly large, overly nested, or mutating variables. SWITCH/CASE: complicated fall-through. FOR: mutating counter variables, mutating termination condition. TRY/CATCH/FINALLY/THROW: exception hell/deep uncaught exceptions. These control flow mechanisms should definitely be preferred to GOTO in most cases but they can be just as badly abused if you aren't careful. The big difference I find is that people are taught how not to abuse these mechanisms but most material about the proper uses of GOTO is almost taboo because of the cargo cult around avoiding its use. Sorry if this doesn't really fit into the discussion but it's interesting to me how an initially very tame and rational counter-argument spawned a massive cargo cult.
- marcosdumay 6y ago
  > but they can be just as badly abused if you aren't careful No, they can't. Old-school goto can create entire new problems in a codebase, that aren't possible to replicate with the structured constructs. That's the entire point of structured programming. Of course, it's possible to use goto well. But eliminating it eliminates the problem.
wavepruner 6y ago
Any good reading suggestions regarding the idea that global variables are harmful?
- finnthehuman 6y ago
  Yes. The largest global-heavy, non-public, codebase you have access to. Reading a treatise on globals if you don't already have the taste to suss out much of the cost/benefit of globals on your own is a recipe for taking the contents out of context and treating the recommendations too broadly/narrowly.
  - commandlinefan 6y ago
    > treating the recommendations too broadly/narrowly That's a good point - mis-applying best practices because you don't really understand them is almost as bad as just ignoring them to begin with.

game_the0ry 6y ago

Agreed. Well-reasoned stubborn opinions that are fleshed out through critical thinking are examples of good opinions. The stubborn opinions from fads, not so much. Those opinions try to signal - 'I am the smartest because I know the latest and greatest.'

jacoblambda 6y ago

The GOTO topic is an interesting one because Dijkstra inadvertently started a cult around the avoidance of GOTO. Dijkstra never intended this and one of the main reasons this occurred was because Dijkstra's original paper "A Case Against the Goto Statement" was editorialised as a letter to the author type article to speed up publication which resulted in the famous title "Goto Statement Considered Harmful". This is a topic where both him and other prominent figures such as Donald Knuth have since its publication repeatedly argued for moderation in use of the GOTO statement and against the total avoidance of GOTOs. My go to example for this is that in C and other languages that lack modern comforts such as exceptions(for better or worse) and destructors, GOTOs can largely simplify the handling of clean-up and error recovery code. Another example is longjmp which is very useful in kernel-space or bare metal programming, and in implementation details for exception handling however outside of those niches, serves no purpose. GOTO serves a very useful niche but can also make code nigh impossible to follow. Most other structured programming statements have the same threat but we have rules in place to avoid their abuse. The following cases can result in code that is just as problematic: IF/ELSEIF/ELSE: overly large, overly nested, or mutating variables. SWITCH/CASE: complicated fall-through. FOR: mutating counter variables, mutating termination condition. TRY/CATCH/FINALLY/THROW: exception hell/deep uncaught exceptions. These control flow mechanisms should definitely be preferred to GOTO in most cases but they can be just as badly abused if you aren't careful. The big difference I find is that people are taught how not to abuse these mechanisms but most material about the proper uses of GOTO is almost taboo because of the cargo cult around avoiding its use. Sorry if this doesn't really fit into the discussion but it's interesting to me how an initially very tame and rational counter-argument spawned a massive cargo cult.

marcosdumay 6y ago
> but they can be just as badly abused if you aren't careful No, they can't. Old-school goto can create entire new problems in a codebase, that aren't possible to replicate with the structured constructs. That's the entire point of structured programming. Of course, it's possible to use goto well. But eliminating it eliminates the problem.

wavepruner 6y ago

Any good reading suggestions regarding the idea that global variables are harmful?

finnthehuman 6y ago
Yes. The largest global-heavy, non-public, codebase you have access to. Reading a treatise on globals if you don't already have the taste to suss out much of the cost/benefit of globals on your own is a recipe for taking the contents out of context and treating the recommendations too broadly/narrowly.
- commandlinefan 6y ago
  > treating the recommendations too broadly/narrowly That's a good point - mis-applying best practices because you don't really understand them is almost as bad as just ignoring them to begin with.