TRWTF is the entire JS ecosystem
-
@CHUDbert said in TRWTF is the entire JS ecosystem:
I’m convinced that satan created JS while on a kilo of crack, a kilo of meth, and a metric shit ton of heroin laced with fentonyl, used motor oil, and ether.
So maybe the next language atrocity was just prevented?
-
@Gąska said in TRWTF is the entire JS ecosystem:
@boomzilla said in TRWTF is the entire JS ecosystem:
@topspin said in TRWTF is the entire JS ecosystem:
There's many valid complaints about C++. I don't think this is one of them.
The "best" operator overload I've seen seems to be
++
and its potential effect in loops.I see your
++
and raise you&&
, which you can overload just fine, but then your ifs lose the short-circuit property.That's indeed a legitimate complaint. But it's not "operator overloading is bad" but "overloading the && operator is bad".
-
@pie_flavor said in TRWTF is the entire JS ecosystem:
@topspin said in TRWTF is the entire JS ecosystem:
How does Rust allow operator overloading but prevent the overloaded operator from being counter-intuitive?
Because overloading is a misnomer. If I see
a + b
for typesA
andB
, that always meansA
implementsstd::ops::Add<B>
and it's callingAdd
'sadd
function. Numbers are no exception; they implement the trait too. The same goes for other operators which in some languages exist by default - there simply is no default in Rust. For example,==
is not usable on any type that does not implementPartialEq
. So when you see==
, it always refers to a trait function. Compare to C++ where you can override what the fucking comma means.And in C++
a + b
always means it's callingoperator +
(which might be a built-in for primitive types). Conversely, youradd
function in Rust can do nonsensical things, too.EDIT: You've already answered that in another post. So let's just say I disagree you're hiding anything by giving the
add
function the more convenient name+
.
-
@topspin said in TRWTF is the entire JS ecosystem:
@pie_flavor said in TRWTF is the entire JS ecosystem:
@topspin said in TRWTF is the entire JS ecosystem:
How does Rust allow operator overloading but prevent the overloaded operator from being counter-intuitive?
Because overloading is a misnomer. If I see
a + b
for typesA
andB
, that always meansA
implementsstd::ops::Add<B>
and it's callingAdd
'sadd
function. Numbers are no exception; they implement the trait too. The same goes for other operators which in some languages exist by default - there simply is no default in Rust. For example,==
is not usable on any type that does not implementPartialEq
. So when you see==
, it always refers to a trait function. Compare to C++ where you can override what the fucking comma means.And in C++
a + b
always means it's callingoperator +
(which might be a built-in for primitive types). Conversely, youradd
function in Rust can do nonsensical things, too.Well, the one thing it cannot do is modify either operand. Because it must conform to the
fn add(self, rhs: RHS) -> Self::Output
interface, and that takes parameters by value. No such restriction exists in C++.
-
@Gąska said in TRWTF is the entire JS ecosystem:
@topspin said in TRWTF is the entire JS ecosystem:
@pie_flavor said in TRWTF is the entire JS ecosystem:
@topspin said in TRWTF is the entire JS ecosystem:
How does Rust allow operator overloading but prevent the overloaded operator from being counter-intuitive?
Because overloading is a misnomer. If I see
a + b
for typesA
andB
, that always meansA
implementsstd::ops::Add<B>
and it's callingAdd
'sadd
function. Numbers are no exception; they implement the trait too. The same goes for other operators which in some languages exist by default - there simply is no default in Rust. For example,==
is not usable on any type that does not implementPartialEq
. So when you see==
, it always refers to a trait function. Compare to C++ where you can override what the fucking comma means.And in C++
a + b
always means it's callingoperator +
(which might be a built-in for primitive types). Conversely, youradd
function in Rust can do nonsensical things, too.Well, the one thing it cannot do is modify either operand. Because it must conform to the
fn add(self, rhs: RHS) -> Self::Output
interface, and that takes parameters by value. No such restriction exists in C++.Okay, but it could still do
rm -rf --no-preserve-root
ifrhs
is 42.More seriously: with rvalue references modifying the operands is potentially useful.
-
@Gąska Well, you find me such a case, and I'll reconsider.
-
@topspin It could also mean it's typedef'd to a number somewhere and is just adding them. The + was a setup for the ==, moreover. I was saying that Rust code, while it can frequently be pretty, is always unambiguous.
-
@pie_flavor said in TRWTF is the entire JS ecosystem:
@Gąska Well, you find me such a case, and I'll reconsider.
The sole fact you can't tell me what the rules are is bad enough for me. Thanks but no thanks; I've reached my new language quota this fiscal year.
-
@topspin said in TRWTF is the entire JS ecosystem:
More seriously: with rvalue references modifying the operands is potentially useful.
The best thing about Rust is that it doesn't have or need rvalue references.
-
@Gąska I don't have to think about what the rules are. Everything just works. The language is simply designed so that it's never ambiguous whether something should be its own line or not.
-
@pie_flavor said in TRWTF is the entire JS ecosystem:
JS's suckage is a function of how easy it is to do, in operations that you think should make sense not because they exist in other languages but because they are simply logical.
"They are simple logical" is a somewhat dubious notion. People have also suggested that assignment operator should look completely different to equality operator (like
:=
instead of=
) because it's easy to accidentally do the former when you meant the latter, and it can be done in many languages where there is a concept to truthy/falsy values.@pie_flavor said in TRWTF is the entire JS ecosystem:
As you tell it, learning to write async code properly was hell before ES6. Great, so people developing code before ES6 got a free pass. Except a ton of people are still developing before ES6 because that's how the software industry works
?
async: false
is about AJAX which is browser JS code, and the only reason to not use ES6 on browser code is to have <=IE11 support. Also callback hell does not apply to AJAX because the callbacks are provided as properties, not function arguments, so you can flatten the nested callbacks into individual definitions.
-
@_P_ said in TRWTF is the entire JS ecosystem:
@pie_flavor said in TRWTF is the entire JS ecosystem:
JS's suckage is a function of how easy it is to do, in operations that you think should make sense not because they exist in other languages but because they are simply logical.
"They are simple logical" is a somewhat dubious notion. People have also suggested that assignment operator should look completely different to equality operator (like
:=
instead of=
) because it's easy to accidentally do the former when you meant the latter, and it can be done in many languages where there is a concept to truthy/falsy values.The point is that 'equals' and 'really actually equals' are much stupider and less intuitive than 'fuzzy equals' and 'equals'.
@pie_flavor said in TRWTF is the entire JS ecosystem:
As you tell it, learning to write async code properly was hell before ES6. Great, so people developing code before ES6 got a free pass. Except a ton of people are still developing before ES6 because that's how the software industry works
?
async: false
is about AJAX which is browser JS code, and the only reason to not use ES6 on browser code is to have <=IE11 support. Also callback hell does not apply to AJAX because the callbacks are provided as properties, not function arguments, so you can flatten the nested callbacks into individual definitions.I see you have not gotten the point. See where @Groaner is bemoaning updating to a platform that is no longer nine years old.
-
@pie_flavor said in TRWTF is the entire JS ecosystem:
@Gąska I don't have to think about what the rules are. Everything just works. The language is simply designed so that it's never ambiguous whether something should be its own line or not.
If it's simple and never ambiguous, why won't you just tell me the rules?
-
@Gąska The rules are that statements can be separated by newlines and/or semicolons.
-
@Gąska said in TRWTF is the entire JS ecosystem:
why won't you just tell me the rules?
Because the rules are that you don't talk about the rules...
-
Okay, now that we know that ASI is shit, is there a switch to ESlint, or some other tool, that would cry blue murder if there would be a semicolon automagically inserted?
-
This post is deleted!
-
@wft said in TRWTF is the entire JS ecosystem:
is there a switch to ESlint, or some other tool, that would cry blue murder if there would be a semicolon automagically inserted?
ESlint is just about as shitty in practice, because they're either configured to be too draconian you're spending time working against it (99% of the time you really just need to run your code through an auto-formatter which most IDEs and code editors has), or configured to be extremely outdated (e.g linter yells at you to "not use ES6 features" if you use ES6 features, when your runtime is Node v11). Both of them are ridiculous.
-
@_P_ Both which, Node and ES6? Yes, very.
-
@_P_ said in TRWTF is the entire JS ecosystem:
As with most things, hackery is unavoidable.
A massive source of hackery in JavaScript is the various holes and bugs in the runtime environments. But here the dynamic nature comes in handy, because you can—and should—monkey patch the polyfills in place of the missing interfaces and treat the environment as compliant in the rest of the code.
-
@Gąska said in TRWTF is the entire JS ecosystem:
Which is funny because the main design goal, the defining characteristic, the raison d'être of OOP is to entangle data with behavior and treat it as atomic unit.
… and these days it is mostly understood by the people without flaps on their eyes that it was a really bad idea.
-
@boomzilla “Hey buddy. Want some cucumbers?”
-
@_P_ said in TRWTF is the entire JS ecosystem:
"They are simple logical" is a somewhat dubious notion. People have also suggested that assignment operator should look completely different to equality operator (like
:=
instead of=
) because it's easy to accidentally do the former when you meant the latter, and it can be done in many languages where there is a concept to truthy/falsy values.What they should have done is used
:=
for assignment and==
for equality, with plain=
being a syntax error. Bye bye forever, fucking that up!
-
@pie_flavor said in TRWTF is the entire JS ecosystem:
@Gąska The rules are that statements can be separated by newlines and/or semicolons.
Does it mean newline is synonymous to semicolon always, in all circumstances? Like in Python (except that Python doesn't have semicolon)?
-
@Gąska Not true that a newline in Python is always synonymous to statement termination.
e.g.
p = ( 1, 2 )
or multi-line function arguments, etc. I don't believe the extra indentation is necessary either.
-
@kazitor it seems that indentation isn't just not necessary - Python ignores all its indentation rules entirely when in parentheses:
>>> def p(): ... return ( ... 3, ... 2 ... ) ... >>> p() (3, 2) >>> def p(): ... return ( ... 2, ... 4, ... ) ... >>> p() (2, 4) >>>
-
@Gąska Hm. It did seem odd to write "I don't believe the extra indentation is necessary" when talking about Python
-
@Gąska said in TRWTF is the entire JS ecosystem:
Python ignores all its indentation rules entirely when in parentheses
Python uses the rule that newline ends a statement… if it is syntactically legal to do so (considering just that “line”, and not whatever is on the next ones). It's pretty easy to cope with: if you want the statement to go onto the next line and you're not sure, slap a backslash at the end of the line. Job done.
And then deal with the linter being fussy about stuff.
-
>>> def p(): ... x = File "<stdin>", line 2 x = ^ SyntaxError: invalid syntax >>>
-
@Gąska That's a higher-level syntax check.
It all feels very natural to me, but then I also write Tcl code and that's even more strongly this way.
-
@dkf said in TRWTF is the entire JS ecosystem:
@Gąska That's a higher-level syntax check.
What does that even mean? How many levels of syntax are there in Python?
-
@Gąska said in TRWTF is the entire JS ecosystem:
What does that even mean?
Basic syntax checking is stuff like “are the parens/brackets balanced”. The second level of syntax checking then delves into the meaning of the remaining symbols.
-
@dkf so it seems that it's correct to say that parens and brackets are special, and other than that, newlines always terminate the statement.
-
@Gąska said in TRWTF is the entire JS ecosystem:
@dkf said in TRWTF is the entire JS ecosystem:
@Gąska That's a higher-level syntax check.
What does that even mean? How many levels of syntax are there in Python?
I think what he's trying to say is that "of course
x =
is an incomplete statement and thus a syntax error", but didn't realize that you got that error before having the chance to complete on the next line of the REPL.But then I might be misreading either of you.
-
@dkf said in TRWTF is the entire JS ecosystem:
Tcl
Is potentially pronounced "tickle" according to Wikipedia.[citation needed]
Huh.
-
@Zecc Yes. Some people say the letters out loud when talking to management.
-
@boomzilla said in TRWTF is the entire JS ecosystem:
And you also talked about ASI. The problem here is that sometimes you forget.
And then it is much better to learn to never insert unnecessary semicolons and learn to see when the newlines do terminate statements.
That's why the standard forbids unnecessary semicolons! See also here, here or watch here. It adds a rule to not start line with the characters that would induce the semicolon to not get inserted instead.
ASI, with the rules used in JS, is a massive , but it ain't going anywhere due to backward compatidebility, so it's better to learn proper rules to deal with it than blindly insert semicolons everywhere and think it'll keep you safe when in most cases it won't.
@Gąska said in TRWTF is the entire JS ecosystem:
actual rules are so complicated that you absolutely have to not worry about it
The problem is the law of leaky abstractions. Any rules that you don't worry about are going to bite you in the arse sooner or later.
@wft said in TRWTF is the entire JS ecosystem:
Okay, now that we know that ASI is shit, is there a switch to ESlint, or some other tool, that would cry blue murder if there would be a semicolon automagically inserted?
Yes, there is. Though the recommended approach is actually to insert all of them and cry bloody murder when semicolon is not inserted; see above (there is a switch for that as well).
-
@pie_flavor said in TRWTF is the entire JS ecosystem:
@Gąska I don't have to think about what the rules are. Everything just works. The language is simply designed so that it's never ambiguous whether something should be its own line or not.
Can you rephrase that in the form of a "why the lucky stiff"-style surrealist illustration?
-
@Bulb this is more or less what I want: a tool “inserts” (in memory) semicolons where ASI would put them, and if the source file doesn’t have that semicolon, emit an error.
I’m not sure ESlint’s “missing-semicolon” rule does exactly this. Please correct me if I’m wrong.
-
@_P_ I think I can specify the level of JS in the eslintrc; my JS is being translated with Babel into something IE11 can understand.
-
@Gąska said in TRWTF is the entire JS ecosystem:
@pie_flavor said in TRWTF is the entire JS ecosystem:
@Gąska The rules are that statements can be separated by newlines and/or semicolons.
Does it mean newline is synonymous to semicolon always, in all circumstances? Like in Python (except that Python doesn't have semicolon)?
No, it means that you can use newline whenever you would otherwise use a semicolon.
-
@Gąska said in TRWTF is the entire JS ecosystem:
except that Python doesn't have semicolon
Python does have semicolon. Suggesting that people use it is akin to suggesting that people use
goto
in C++…
-
@dkf I forgot about that! Now I have this pressing urge to continue formatting my Python scripts "correctly", but terminate every statement anyway.
-
At first I wanted to point out all the logical fallacies in this wall of text, but then my brain overflowed.
-
@levicki we've just been through this, although I don't remember in which topic.
-
@levicki I'm all for banning all human-written
JMP
instructions.
-
@Gąska said in TRWTF is the entire JS ecosystem:
@levicki we've just been through this, although I don't remember in which topic.
Start heregoto: https://what.thedailywtf.com/post/1470878
-
@Gąska said in TRWTF is the entire JS ecosystem:
I'm all for banning all human-written
JMP
instructions.They certainly have no place on an ARM, that's for sure.
-
@levicki said in TRWTF is the entire JS ecosystem:
@dkf said in TRWTF is the entire JS ecosystem:
@Gąska said in TRWTF is the entire JS ecosystem:
except that Python doesn't have semicolon
Python does have semicolon. Suggesting that people use it is akin to suggesting that people use
goto
in C++…Hey, what's wrong with
goto
?!?More love for
longjmp
!
-
@PleegWat said in TRWTF is the entire JS ecosystem:
@levicki said in TRWTF is the entire JS ecosystem:
@dkf said in TRWTF is the entire JS ecosystem:
@Gąska said in TRWTF is the entire JS ecosystem:
except that Python doesn't have semicolon
Python does have semicolon. Suggesting that people use it is akin to suggesting that people use
goto
in C++…Hey, what's wrong with
goto
?!?More love for
longjmp
!:deathfirst.webm: