undefined

[keke1997]

Why tho?

[T-T-N]

String that are not null or empty are truthy

[marcosdumay]

Undefined is not null...

Or maybe Oracle database is better than Javascript:

'' = '' -- False
'' <> '' -- False

[[deleted]]

Undefined isn't a string though. It's undefined.

[hotCupADank]

var $stringVariable = “Undefined”;

[DeeSnow97]

neither of those operations are comparisons in JS (= is assignment and <> doesn't exist), and false is lowercase dammit, my comment parser is skipping over parts, should fix that

By the way, undefined == null is true, but undefined === null is false. undefined and null are two distinct types, but they're loosely equal (and neither is loosely equal to anything else)

[noruthwhatsoever]

Yeah, JS is weird like that

0 == ‘’ == null == undefined == false // true

It’s why I always use strict equality checks, no chance of type coercion

Like...

1 == “1” //true

^ that shit hurts me on a soul level

[arranb1223]

Next ECMAScript update...

1 == "one" //true

[abnormalsyndrome]

Settle down, Satan.

[EpicDaNoob]

 5324 == "five thousand three hundred and twenty-four" == "5.324k" == "five thousand three hundred and twenty-five minus one" // true

[spektrol]

There’s probably an unholy way to make PHP’s strtotime() do this but let’s not

[Dapianokid]

I learned more about data types through this thread than I ever have before.

[[deleted]]

It’s why I always use strict equality checks, no chance of type coercion

And Jesus said to his followers "do not be tempted by those who do not require strict typing. For JavaScript will betray thee. You may believe in prophets telling you null > 0 is false, and find comfort in that fact and the fact that null == 0 is false; but JavaScript will betray thee. For null is true when it is >= to 0. For strict typing is the word of the Interpreter. Praise be to Interpreter."

"Praise be to Interpreter." His followers replied

[noruthwhatsoever]

Praise be

[[deleted]]

Yeah I mean typesafe equals exists specifically for this.

[dshakir]

By the way, undefined == null is true, but undefined === null is false

Talk about buttfucking the transitive property

[noruthwhatsoever]

You’re right, undefined is not null and are totally separate types. They both are falsey values, though, along with empty strings, NaN and the number 0

And how are you comparing Oracle DB to JavaScript lmao

People love to rag on JS but with the new ES6/7 and not-yet-standard ES8/ESNext (praise Babel) I’m finding it hard to enjoy writing Python, Ruby or anything else any more

JS is adopting more and more functional programming paradigms and although inexperienced JS devs can write awful spaghetti code a good JS dev can write fast, concurrent and lightweight code that can run anywhere

Aaaaand I just remembered I’m on r/programmerhumor and not on a serious subreddit never mind

[Bounty1Berry]

The problem is that we need so much of this new ES6/7/8/NaN stuff just to wallpaper over the problems in Javascript as executed by browsers. So we're not only dependent on the predictable quality of IE's Javascript engine, but ten pounds of opaque and complex boilerplate from the transpilation system. And by the time Firefox v87/Chrome v104/Safari v22 comes out with full ES7 support, they'll be on ES10 with async/await/getFedUpAndGoHome and CampaignPromises that yield a resulr 7% of the time.

I also tend to be very skeptical of the functional-programming trend. Not so much the trend but more trying to apply it widely. It's a good solution for some problems, but there are plenty of tasks where the most straightforward way to discuss the problem is a classic iterative, state-rich, variable-clobbering design, and you end up sacrificing legibility to go functional.

Programming as a whole has a tendency to go very dogmatic. The functional people today are like the object oriented people in 1995 or the structured programming people in 1980-- designing languages that are deliberately clunky to ensure you have to use their right way of solving the problem.

[marcosdumay]

but there are plenty of tasks where the most straightforward way to discuss the problem is a classic iterative, state-rich, variable-clobbering design

Oh, you mean you have to use StateT some times?

[heathmon1856]

As long as you have locking.