Search for a command to run...
Stop exposing your lack of comprehension /experience by making definitive statements about things you do not fully understand.
None of what I post is "ai" generated. "AI" does not exist and what is being called "ai" vomits up misinformation as facts mixed in with a sprinkling of actual facts to make it extremely harmful to use.
What you read here, I wrote.
"Go has as many opinion based mistakes baked into them to replace the mistakes they avoided"
could you please give some examples, just out of curiosity
This is a series of articles that explain the pitfalls of failing to think critically about things that are presented with authority and followed dogmatically with out any factual basis.
the development process that can be named is not the true development process
simplify your data management by using Pinia Persist plugin and StorageLike
null means data is missing but provides no semantic meaning for its absence. providing why it is missing is critical for data integrity
non-contrived examples of how iter.Seq, iter.Seq2 and their iter.Pull allow for zero cost abstractions to make your life better
iter.Seq/iter.Seq2 is a very Monadish way of iterating of a sequence of data and I really like it.
anyone seriously comparing Rest to GraphQL does not know why either of them exist.
I keep seeing articles that demand the reader "Stop doing" something that is fine practice, if not good/best practices just because they saw some demo on youtube and that person was not doing that thing and it now gospel to never do it again.
This is a very concrete example of advice that is at best ignorance and at worse malicious misinformation.
If you google "stop using else" you will get pages and pages of articles written mostly by people that only have passing experience in a single language, usually JavaScript, and have never had to maintain a program with total lines of code greater than 10K, espousing this nonsense as if it was a revelation of some new gospel.
Its not, it is an ancient screed from the Cult of the Lines of Code Gospel or the Followers of the Optional Braces disciples repeat these mantras and have no experience with what they are saying in the larger picture.
This is from PEP 20 - The Zen of Python but it applies to all higher level languages and is knowledge that was learned from working with previous languages that were dominated by the "Cult of the Lines of Code" acolytes, this cult still preaches such things as the First 80 Columns are the only holy columns fallacy in 2022 as well.
This statement should be self explanatory and non-controversial. Program code that is explicit is unambiguous in its intent on what its behavior is expected to be.
That is not to say that its behavior is correct, it is just that it is not a mystery what the desired output of any input is expected to be. Executable Code should be the definitive source of logic, and comments are not executable even if they are semantically code.
The same cult that is espousing this nonsense now is the same cult that exposed the nonsense of leaving off {} from if statements and for the exact same reasons.
The most popular ones are, "they are not needed", "they increase lines of code or keypresses", "they are more to read", etc. All of them are backed by logical fallacies as why they are correct.
Leaving off an else statement never adds any information, it removes information about what the code is intended to do. Anything that removes information in this case is harmful.
Leaving off the else block in languages like Python are even more harmful than the languages most of these authors are using to justify their ideology. Go and JavaScript I am looking at you.
The lack of block characters, or leaving off block characters (which is worse), makes these types of logic bombs even harder to reason about when they explode and you can not see where the issue is just looking at the code. Especially, when they cause intermittent bugs because the bad logic only triggers occasionally based on some state machine that is not defined and impossible to reason about when the application is running much when you are looking at the source.
This stop using ??? advice is primarily predicated on bad advice that the reader does not comprehend as bad advice because of lack of comprehension from lack of experience.
These same people will mindlessly espouse concepts like DRY and SOLID, avoid side-effects and completely ignore that this advice introduces implicit logic solely based on side effects.
The reasoning in this case is basically some form of "else is just fluff and adds nothing useful" and then follows with "you should code theif clause and return inside it and then do whatever the else is without the else statement and return there". There is a Luke Skywalker quote from a terrible movie that applies to this but I will not subject you to here.
This is terrible practice and it immediately introduces an impossible to detect bug into the logic of the code. Maybe not one that causes incorrect output immediately, but one that can the very first time someone adds any code outside that initial if block.
The misinformation is that the if statement is a special case in some way and that the else is the default/non-special case and does not need special treatment or demarcation.
The fact that you can transpose this specialness just by changing the initial if to if not tells you this is a flawed reasoning.
if not somethingSpecial:
doSomethingElseNotSpecial()
doSomethingSpecial()
Note that there is something even more fundamentally wrong with one of these pseudo-code logic above other than the missing else but that is another religious argument where the zealots are wrong as well.
null has been called a Billion Dollar Mistake by its creator. It is arguable that he was off by at least an order of magnitude initially, multiple orders by 2022 standards.
It was just one of many terrible ideas that language creators implement because most of them were not trained in formal logic or even trained in writing computer languages or they are trying to design for flexibility in the future.
Many popular programming languages were created out of some need as a tool as a means to a very specific end, until C. C was created to be a general purpose language, and as such includes a kitchen sink of bad ideas that are only obvious in hind sight, sometimes even with 50 years of hindsight they are still obvious to some people.
One of the most subtle bugs in C is the one line if statement, that leaves off the {}. If someone comes along and just adds another line of code below the initial line in the if statement, what were their intentions?
Usually their intention was to add that line to the if statement, but that is not what happens. It is just executed regardless, which introduces can be an extremely subtle bug that can decimate data in an very quiet way that may not become apparent for hours, days, weeks or even months later.
Leaving off the else introduces the same class of bug, if not always the same level of subtly.
Languages like Go that are planned and designed for a reason just as a reaction to some problem leave a lot of these organic mistakes behind.
Unfortunately Go has as many opinion based mistakes baked into them to replace the mistakes they avoided. Which personally I think is worse, because these mistakes are based on intention instead of accident. They become dogma immediately, no matter how bad they reveal themselves to be.
This dogma becomes a defining aspect of the language that drives away adoption because it is expected to be adopted by everyone; regardless of how bad an idea it actually ends up being, instead of cautionary tale features that are accepted as being avoided.
NOTE: I do not hate Go, I have moved to using Go over all the previous languages I usually reached for before I learned Go. Go is a great compromise that can completely replace Java and Python at the same time. Instant compiles of even huge programs means it can be used for rapid development scripting type tasks, cross platform single executables with robust libraries and frameworks ticks the Java boxes. It is great, but not perfect.
One of the most offending languages right now to this is Go. There is a preponderance of effort into pushing the idea that else is not needed, and if it is your code is not structured enough or some other hand wavy non-sense that is your failing and not the failing that it is a terrible practice.
Another, idiom of Go is the normalization of negative Boolean checks in if statements.
This is the idiom in Go, and it is terrible for many reasons.
First off, the general and correct consensus is that the initial if statement should be not be testing for a negative because it forces more processing on the organic computer that is parsing and interpreting the intent of the logic.
Who in their right mind would let the following type of code construct into an application that was used for anything non-trivial?
if x != true && y != false && z == true {
// do something for some reason
}
Yet, I have seen thousands of lines of such checks in 20+ year old Java code that the original author insisted was "best practices" 20+ years later. Lucky for me that IntelliJ idea was able to automatically convert them all to something easier to reason about using structural search and replace.
We still had to reason about the multiple checks and normalize that, but it did save time and make writing tests for this code possible.
The Go idiom is not exactly the same, but is in the same class of obfuscated logic for the sake of brevity, even if you consider it less harmful than the Java example. Less harmful is not harmless.
Go codifies the "multiple return" religious argument dogma by making it an idiom. It does not solve the argument, it justifies it as "everyone says so", which is just a logical fallacy.
It does this, by making this the idiom in all the official Go source code.
This also has the side effect of justifying that else is never needed and thus it is idiomatic as well to always leave it out.
Leading many people to twist otherwise clear logic in obfuscated knots and write spaghetti code to be able to leave it out.
Documents that had important information that needed to be unambiguous in their facts and intention always have blank pages that say THIS PAGE LEFT INTENTIONALLY BLANK, on them in huge block letters. That way no one would wonder if that blank page was supposed to be blank and missing information? Was it a printing error? Is there missing information that could be a cause a serious error? No one would argue these semantic place holders were redundant or not important in the explicit context that they provide.
The else in the if/else symmetry serves this same semantic function. It says explicitly, THIS AND ONLY THIS is what is supposed to happen if the other thing is not true and leave no ambiguity.
It says, if you want something to happen if that special case is not true put it here. If you want something to happen regardless of that space put it outside here.
// something that might return an error
if err != nil {
return err, nil
}
// something ELSE or something unrelated to the previous if we
// have to look and parse to know that might return an error
if err != nil {
return err, nil
}
return nil, somethingNotNil
is what most would consider idiomatic the following is not wrong but is preferable because of it is explicit and unambiguous to the expected behavior
if err != nil {
return err, nil
} else {
return nil, somethingNotNil
}
the needlessly laconic idiom version saves an entire 7 characters, but is introduces the possibility of endless subtle bugs as unattended side effects, incorrect logic and just bad output.
Thankfully, even this idiomatic structure is being challenge by the new/late comers to Go, but in an early enough stage and by enough seasoned developers that it can hopefully be corrected as harmful dogma from early zealots.
The fact that if err != nil is well considered to be just copy paste boilerplate with dozens of macros, libraries, frameworks, and code generator solutions to this should tell you it was never a good idea.
It is very simple:
If the advice in any way makes your code less explicit, introduces any kind of possibly ambiguousness or obfuscation to the intent of the logic expressed as code, then ignore that advice.
This should tell you that all these stop using else articles just as bad for the industry as the same arguments espoused on Usenet in the 1980s promoting omitting optional braces in C for the same incorrect reasons.