damn it... I guess I should move

I hear the weather is quite nice in undefined this time of the year.

By any chance are u in Japan?

All your life, you've been told Lithuania exists and you live there.

Damn you're in the backrooms

@electrineer Finland also doesn't exist. It's just eastern Sweden made up by the Japanese and Russia so they could fish there without being bothered. The fish gets exported via Russia to Japan using Nokia containers. It's named FINland because of the fish

Watching it on 70mm next week ☺️ so damn excited

When do we get a movie about the most horrible invention in human history: JavaScript?

@Lensflare it goes by the name The Human Centipede

@chonky-quiche Ha! Totally underrated comment. That’s amazing.

@chonky-quiche @root

I don't get it..

nvm, got it :D that's cruel though

@Lensflare Geofencing and arbitrary market separation aren't JavaScript's fault. The language is shit - but it isn't the cause of _all_ evil.

@Oktokolo that’s not the point. A good language would force you to handle the edge case of an unknown location. Depending on the language it could be enforced by utilizing nullability or optionals or the try/catch mechanism.
The dev would then decide to show a different message or no message at all.

With JS, the only way to find those edge cases is to see them occur in production (like we see here) or to make endless unit tests for everything, and it will still be not guaranteed to be found.

@Lensflare agree with @Oktokolo here. An empty string or exception would not lead to a better experience.

@hjk101 do I really need to explain the obvious?
Let it be something like "Your location could not be determined. This site is for users in USA".
That’s better than "undefined" in place of the location.

@Lensflare yea I don’t see how it can be boiled down to a JS-is-at-fault problem. I’m guessing it’s just a bug.

@chonky-quiche That’s exactly why JS is so harmful. It makes devs not even realize that there is a problem and that it could be solved with better language.

I’ll explain with some pseudocode:

let’s assume there is a function to produce the message that the user will see:

func message(var userLocation: String) -> String {
return "Your location is {userLocation}"
}

And there is a function that returns the location:

func userLocation() -> String? { … }

It returns an optional or nullable String because it might be unknown.

An alternative would be throwing an exception or error.

So, we use those functions like that:

message(userLocation())

JavaScript is completely fine with that. Nothing wrong here. And then you see that crap message in production at some later point in time.

With a good language, the compiler tells you that you are passing an optional value to a function that expects a non optional value. Or you are not catching the thrown exception.

… You are aware of the fact that there could be a problem and you NEED to handle that. How you handle that is up to you but you just prevented a bug from ever happening.

It’s a really basic concept. And it’s sad that it’s so hard to wrap your head around for some devs apparently, especially those used to crap languages like JS.

@Lensflare would it be a good idea to use compiled languages for the web on the FE? If so, why hasn’t JS been replaced already? The intention of JS is to be as versatile as possible, so the responsibility of error/null checking is in the developers hands mostly. If you need these kind of checks all the time, I would recommend typescript.

@chonky-quiche typescript is an improvement, yes. And it could have prevented this bug in particular, if used correctly.
I’m just pointing out that JS is in fact the problem (because some of you didn’t believe me).

@Lensflare ok but what r u gonna do about it then if it’s such a huge problem

@chonky-quiche nothing. I can’t do anything and it’s not even my problem. I’m not using JS.

Btw. the whole error/null check thing (or rather the lack of it) is not due to "versatility".
That’s just something that JS lovers like to tell to them selves to feel better.

And the argument "it’s good because nothing has replaced it yet", is flawed for obvious reasons.

@Lensflare I thought I don't have to spell it out for you but that is a specific case that needs to be programmed. No programming language is going to know that an empty or default "location not found" response is going to result in that desired behaviour.
It needs to be programmed. Just like you need to do it in JS.

@Lensflare Sure, there also is a "compiler should have enforced a check here" bug here. But TypeScript already exists and with the correct strictness settings, it solves this. What is left isn't a technical problem. It is a social one - and it's not the choice of language...

@hjk101 @Oktokolo "compiler enforced check" is exactly what I’m talking about. It IS a problem of the choice of the language. Quite literally. Because there are better languages that could have prevented this bug.

I don’t know what appears to be unclear here.

@chonky-quiche @lensflare

it's so fun to watch you guys chew on each other's throats that I almost don't even want to reveal the fact that I got this 'error' with NotScripts blocking that site :)

carry on, don't mind me

@netikras lol 😄

That’s weird. How do you explain that interpolated "undefined"?
Is it a static site with that exact string?

@Lensflare idk, idc really. but when I whitelist that site in NotScript, the undefined transforms into Vilnius no problem :)

@Lensflare look for

"It looks like you’re in"

in

view-source:https://oppenheimermovie.com/ticket...

$ERROR_SHOWTIMES_LOCATION":"It looks like you’re in %USER_CITY%, and this page is for users in %APP_REGION%"

@Lensflare perhaps you can show me what language + feature would have prevented this bug.

@hjk101 I already told what feature. Optionals in Swift/Kotlin/Rust/C#. Or checked exceptions in Java/Swift/Kotlin/Rust.
Even TypeScript could prevent this because you can demand a value to be not null/undefinded at compile time, afaik.

@Lensflare I know those features well and that wouldn't have prevented it. That is why I wanted to see the code. Kotlin for example has a nice feature with enums that requires everything of the type to be handled in the when statement. The problem is that either there is a case likely generated by the IDE to just do nothing with on null or there is an exception on the conversion to the enum.

More likely there is some object retuned that has a location/country string. The string will only be dereffed if the object is not null. Otherwise it will likely be an empty string.

Now it is true that these features do help in preventing accidental thoughtlessness but it will not force the exception cases to be handled properly. I think you are a good engineer and would think it's obvious to handle these cases properly. I've had the displeasure to work with the less gifted and wish I would always have to work with someone of your stature. My face would have had far less palm prints.

@hjk101 I think we all agree that you can do bug free stuff even with a shit language and you can fuck up with a good language if you are a shit dev.
That‘s not for debate.

The point is: A good language helps writing good code.
It does prevent many bugs when you assume that the dev is not a monkey and the libraries and frameworks are utilizing the language‘s features.

You can write Kotlin as if it was JS but that‘s the wrong way of writing Kotlin.

You can not write JS as if it was Kotlin.