I’m addressing the bit that I quoted, saying that an interpreted language “must” have valid semantics for all code. I’m not specifically addressing whether or not JavaScript is right in this particular case of min().
…but also, what are you talking about? It throws a type error if you call min() with no argument.
Without one, the run time system, must assign some semantics to the source code, no matter how erroneous it is.
That’s just not true; as the comment above points out, Python also has no separate compilation step and yet it did not adopt this philosophy. Interpeted languages were common before JavaScript; in fact, most LISP variants are interpreted, and LISP is older than C.
Moreover, even JavaScript does sometimes throw errors, because sometimes code is simply not valid syntactically, or has no valid semantics even in a language as permissive as JavaScript.
So Eich et al. absolutely could have made more things invalid, despite the risk that end-users would see the resulting error.
All the others are not very butthole-ish, though.
It’s not in C, if that’s what you mean.
It’s a “stream manipulator” function that not only generates a new line, it also flushes the stream.
Probably moreso for expressing the opinion so strongly without actually knowing any of the three languages.
Edit: I’m just guessing why a different comment got downvotes. Why am I getting downvotes?
Doesn’t the first edition use K&R style parameter lists and other no-longer-correct syntax?
In addition to not actually being correct, I don’t think the information you’ve provided is particularly helpful in answering OP’s question.
The first part is confusing what “middleware” means. Rather than “duplicating” functionality, it connects libraries (I’m guessing this is what you meant). But that has nothing to do with a language being compiled versus “directly executed”, because compilation doesn’t connect different services or libraries; it just transforms a higher-level description of execution into an executable binary. You could argue that an interpreter or managed runtime is a form of “middleware” between interpreted code and the operating system, but middleware typically doesn’t describe anything so critical to a piece of software that the software can’t run without it, so even that isn’t really a correct use of the term.
The second part is just…completely wrong. Lisp, Fortran, and other high-level languages predate terminal shells; C obviously predates the shell because most shells are written in C. “Most original code” is in an actual systems language like C.
(As a side note, Python wasn’t the first scripting language, and it didn’t become popular very quickly. Perl and Tcl preceded it; Lua, php, and R were invented later but grew in popularity much earlier.)
Pretty much all languages are middleware, and most of the original code was shell/bash.
What? I genuinely do not know what you mean by this.
It is similar to old error codes, but I feel that this makes one always have to be mindful of error handling and the non happy path
Technically you need a separate linter (errcheck) to ensure you don’t just ignore errors. This is…not great. (That should have been a compiler error.)
My point is that the claim in the comic and in other comments that this corrupts your repo or loses work simply isn’t true.
It’s not even actually that bad, at least not since January of 2020: https://stackoverflow.com/a/59687740/1858225
Huh. I had forgotten that git does actually create a file with the branch name. But it doesn’t actually screw up the .git folder or lose your data when you try to do a rename like this; it just rejects the rename unless you also use the “force” option. This has been the case since at least January of 2020. But apparently it actually doesn’t always use a local file for branch names, so sometimes there’s a problem and sometimes there isn’t, which I guess is arguably worse than just having consistently-surprising behavior.
I honestly don’t even understand the joke. Case-insensitive file names cause problems, but what does that have to do with version control branch names?
Yeah, consistency is good, which is why it’s good to follow the spec. I’m saying that the decision to make errors be flat strings in the spec was a bad one. A better design would be what you have, where code is nested one level below error, plus permitting extra implementation-defined fields in that object.
The spec requires errors to be a single string, and also mandates using the space character as a separator? I’m not a fan of deviating from spec, but those are…bad choices in the spec.
The article is more about the behavior of members of the C++ committee than about the language. (It also has quite a few tangents.)
In the universe where the list is sorted, it doesn’t actually matter how long the destruction takes!
Most of those comments are actually just random people arguing about the merits of the experiment, not continued discussion with the bot.
Also, the bot is supposed to be able to run builds to verify its work, but is currently prevented from doing so by a firewall rule they’re trying to fix, so its feedback is limited to what the comments provide. Humans wouldn’t do great in that scenario either. (Not to say the AI is doing “great” here, just that we’re not actually seeing the best-case scenario yet.)