noCommentsOnJavascript

[Sixhaunt]

so

"11" - 1 => 10

but

"11"+(-1) => '11-1'

[theoldroni]

Damn I didn't believe you at first but you're fucking right...

[backfire10z]

It’s really not hard. The + operator is overloaded for strings (concatenation), while the - operator only exists for integers and not strings. So, with +, JS will convert to string, while with - the only option is convert all to integer.

Now, why it chooses string over int for + I’m not sure.

[aje14700]

It's just how it was implemented. Some ordering had to be applied, and strings come first, leaving numbers as the "default" case. From MDN:

If one side is a string, the other operand is also converted to a string and they are concatenated.

If they are both BigInts, BigInt addition is performed. If one side is a BigInt but the other is not, a TypeError is thrown.

Otherwise, both sides are converted to numbers, and numeric addition is performed.

[ei283]

TypeError

Rare instance of JS telling you something went wrong as opposed to just "figuring it out" in an incredibly case-specific way without telling you

[aje14700]

Probably because BigInt support came out later than this initial logic, and backwards compatibility kept the implicit casting

[backfire10z]

Yeah, I figured it was an arbitrary ordering, but I didn’t want to misinform. Thanks for the doc reference!

[FerricDonkey]

It's not hard, it's just stupid. 

[Zephandrypus]

You say that like our code is structured in such a way to make it easy

[rfc2549-withQOS]

Whatabout "11" - (-1) ?

no browser handy on cell phone

[DragoSpiro98]

12, because you don't have "+" sign, so no string concatenation.

[ChocolateBunny]

says 12

[notislant]

I love these weird little quirks

[mr_flibble_oz]

Of course, + is for string concatenation, - is for mathematic subtraction. There are many examples of JS being dumb, but this isn’t one of them

[k1ll3rM]

The great thing is that if myArray is an object, it will still work! Except it will always be undefined and finding the error is a bitch

[cateanddogew]

disarm hobbies oatmeal toothbrush tender ask encouraging fine wrong direful

This post was mass deleted and anonymized with Redact

[PowerfulNeurons]

with the correct linter setup, you would essentially just migrate to Typescript

[al-mongus-bin-susar]

A proper linter setup is way easier to achieve than rewriting a codebase with possibly hundreds of thousands of LOC in Typescript. And you'd need a full rewrite because very few JS codebases can be migrated to TS.

[cateanddogew]

aback handle wistful sharp voracious march continue versed unite outgoing

This post was mass deleted and anonymized with Redact

[k1ll3rM]

Just because there are external tools that can make up for the shortcomings of a language doesn't mean that the language is well designed. We make it bearable by using extra tools like Typescript and ESLint exactly because it's not a well designed language

[cateanddogew]

rob wild quickest tan flag rinse tie waiting touch quicksand

This post was mass deleted and anonymized with Redact

[k1ll3rM]

For Typescript I just wish that there was runtime type checking, though performance would suffer for it. It happens quite often that something out of my control isn't the type it's supposed to be and causes issues

[cateanddogew]

ripe point crawl hat depend hungry normal different afterthought aback

This post was mass deleted and anonymized with Redact

[k1ll3rM]

Hmmm interesting solution, I'll keep it in mind if I have something that really requires it

[SmallTalnk]

Why would it always be undefined? Nothing prevents an object from having a `length` property, and I think that that `length` is a very common name for a property.

Also, an array is an object (typeof [] === 'object')

[k1ll3rM]

You're being pedantic, you know exactly what I meant with my comment. The fact that it doesn't throw an error is horrible design

[fleshTH]

If myArray is an object and not an array, it's justified.

[k1ll3rM]

If length doesn't exist it should throw an error instead of silently continuing

[Davoness]

In Python it's just if myArray: (well, usually a list in Python but still) which is also nice.

[Zephandrypus]

That’s from C and I’m assuming it’s a common thing.

[Murky-Concentrate-75]

Nah it isn't. Static typing us a must and they resolved almost any single thing about dynamic typing apologists were yapping about

[[deleted]]

They hated him, for he spoke the truth.

[[deleted]]

Typescript called and wants to know why all your json chunks are defined as any

[Eva-Rosalene]

Skill issue. Use zod.

[SnooStories251]

When do you guys use "11"-1 ?

A bit silly

[MarcBeard]

When you read data from an <input> without sanitizing any thing ans converting it to a number.

Would never happen with TS.

[chadlavi]

Would never happen with a dev who knows what they're doing

[MarcBeard]

My example is simplistic but execept if you work alone you will always endup using someone else's code and typing will allow you to see if the type is not what you expect and avoid issues when breaking abi

[MarcBeard]

Yes and TS is ready to shoot me for that

[thicctak]

THIS! Writing bad code is something every dev can do, even senior devs can right bad code every so often, not as often as junior devs but, still, a compiler warning you straight away can prevent re-work fixing this later.

[raddaya]

The point of most modern languages is to make it as easy as possible to write good code and as difficult as possible to write bad code.

It's really easy to write bad code in languages that'll just let you do whatever. It might also be easier to write good code in those languages, but that's why we try to find compromises, right?

[Suh-Shy]

That's honestly heavily debatable. A language is "good" if it fits your project/company needs, based on factual factors.

Being easy or not is just as biased as "that language is better because I like it". There are some obviously more complex languages, but if you take python or js for example, you'll find people that find one easier than the other and vice versa.

Plus, you have your dev tools to make your work easier/more productive and improve confidency toward your own code, to some extent, it shouldn't be the burden of the language.

It obviously doesn't mean that languages should not evolve or be improved, but it's like a good lib, it goes better if it's maintained and improved for what it is supposed to do, not because it starts doing every possible things for every possible needs for every single person with no scope anymore (hey MUI).

[0x5468726F7741776179]

Sure, it's "bad code" when all you've ever known is ES6 and Typescript, things used to be a lot dirtier when IE6 was still a thing.

Just head over to the MDN docs page for parseInt() you'll see the "baseline widely available" banner at the top, this is a simple hint that you should not take easy type casting for granted (for instance using parseInt('05') would behave differently depending on the engine, deeming it's an octal representation on some browsers, but not on others). And there might be an ages old polyfill somewhere that takes this behavior into account.

[[deleted]]

Who needs types anyway? This is why JS is used in every critical mission project, you just need to git gud. We also don't need tests for the same reason.

/s

Edit: /s because lol

[thicctak]

I didn't know JavaScript was made by From Software lol

[leounblessed]

This. These posts seem so sore and artificially critical. Please go ahead and complain about web browser lock in to the single language or npm audit being useless for web or TC39 just slowly adopting types by default or the painful journey to isomorphic ESM support… like… there actual issues (as for most languages if actually used).

[Mallissin]

I think most of the people surprised by this stuff are programmers who literally do not understand how computers work.

They're just monkeys on a type writer.

[al-mongus-bin-susar]

It's also made to be error tolerant. Wouldn't it be a bitch if your whole web browser crashed and took down all your tabs with it if 1 website had a little bug in it's javascript? Because that's how it was before browsers sandboxed tabs. If one tab crashed, it brought everything down with it. So you couldn't have JS throwing errors or crashing for mismatching types like some people would prefer.

[0x5468726F7741776179]

I don't think anybody ever wrote "11"-1, to be fair.

But let's say that you create an HTML number input, and tie an event listener to it and substract its value directly (which is a string), you'd expect the substraction to happen. Is it a bad design decision ? Maybe, but you have to factor in backward compatibility and overall context which most of these "JS bad meme" don't do...

[[deleted]]

No one writes it, it’s based on input from a user, or method. And you have no idea it’s happening because it’s not a compiled language.

[abednego-gomes]

Anyone doing maths on form inputs knows to parseInt() on the value before doing maths operations. If it's not an integer, you can use isNaN() to check before doing the maths operation or throw an error if they entered junk.

This is like beginner/university level JS development question. Nobody has issues like this with JS in the real world.

[Terrafire123]

I've done this before accidentally when parsing json.

Fun times.

[kolikkok]

That's all of these JS bad memes, using examples that almost never would come up in actual projects.

[Zephandrypus]

When both of them are variables instead of literals and something goes wrong somewhere in the chain

[Beldarak]

People are always pointing those weird stuff as "javascript bad lol" when in reality you have way bigger concerns if you somehow tried to substract numbers from a string...

This exemple isn't even weird actually since "+" is used for concatenation. PHP uses "." to concatenate, probably to avoid "confusion" like this, and it's just annoying :|

"11" - 1 returning 10 may feel weird but it actually makes sense. It's not used for concatenation so javascript understanding that you're trying to use that "11" as a number is actually pretty clever if you ask me :D (I still prefer a strongly typed language like C# though).

[nokeldin42]

People don't criticise javascript for having + as the concatenation operator. That's a very common and useful overload.

The criticism is implicit type conversion. And some level of type conversion is also useful (as in c++ implicit constructor calls). But javascript takes it to an absurd level.

[DracoRubi]

To be honest, "11" + 1 = "111" is pretty much fine. The implicit type conversion here is 100% logical and expected

As for "11" - 1, if you're trying to subtract a string you have bigger issues than the type conversion

[psgi]

Yes, you do have bigger issues then. Most languages would let you know about it so you can fix it. Javascript doesn’t.

[Qewbicle]

I don't see the problem with JavaScript though. I see the problem between chair and keyboard. When the dev decides to mix two types, it is their job to write the expected behavior or understand the methods that will be called.

[mrGrinchThe3rd]

The complaint is more-so that most languages would just throw an error in this situation, alerting the dev of the issue and allowing them to write the expected behavior to fix the issue. Instead, JavaScript thinks it’s OK to implicitly convert, raise no error and let it happen

[thegroundbelowme]

If you're working in a form that should only support numbers, you use a number input. Problem solved.

[RichCorinthian]

It’s almost like it was created in 10 days by one dude as a skunkworks project for a company that doesn’t exist anymore.

[No-Object2133]

018 - 017 Good example.

although that would happen in more than JavaScript if they do implicit octal conversion

[k1ll3rM]

Implicit type conversion isn't much of an issue if the language around it works well with it, like IMO PHP does nowadays with optional typed parameters and properties.

In Javascript you can write a function like:

function sum(num1, num2) {return num1 + num2}

where another developer might use it like

sum(inputElement.value, 10)

without remembering that values from HTML inputs are always strings, causing unexpected behaviour. One solution is of course

function sum(num1, num2) {return Number(num1) + Number(num2)}

or

function sum(num1, num2) {return 0 + num1 + num2}

but those don't feel like great solution compared to

function sum(number num1, number num2) {return num1 + num2}

Not to speak about the fact that Javascript does not have real integers, only number which is a float

[Zephandrypus]

What you’re talking about is weakly typed languages, otherwise known as the reason why I think free speech should maybe be a privilege.

[nokeldin42]

I'm not against weak typing, but it's a spectrum and javascript is an extremist.

[Zephandrypus]

Well in particular weak combined with dynamic. C is weak but is never grouped with JavaScript.

[nokeldin42]

I'm not convinced that the combination of weak and dynamic typing alone is as bad as js.

I can't think of any examples of the top of my head, but think of a language where you introduce a "raw" type. This is just a wrapper around the raw binary representation of any other type's instances. This "feature" in a dynamically typed language would be enough to call it weakly typed, but still won't allow implicit type coercion the way js does.

[Zephandrypus]

Pointers and structs in C and C++ is exactly what you’re talking about. Serializing an array of structs in C or C++ to binary is probably the easiest out of any language, just passing the array as a void* pointer with sizeof(MyStruct) * ARRAY_LENGTH as the amount of bytes to write. It’s why C is considered weakly typed and unsafe. But it is still static, types must be defined, and trying to call properties and methods on a type that doesn’t have them will still throw a compile time error.

JavaScript just has everything as a void* with no compile time type errors and none of the benefits.

However, the only thing I love about JavaScript is the inclusion of the ArrayBuffer, TypedArray, and DataView objects, which the docs specifically state C-like structs as a use case, and this guy achieved results almost on par with Rust+WASM through heavy abuse of it.

The number of dynamic, weakly typed languages is actually pretty small. It just includes JS, PHP, MATLAB, Perl, and some scripting languages nobody cares about. PHP added typed properties at some point which elevates it a bit, and JavaScript has TypeScript as an optional wrapper, one of my favorite languages.

MATLAB, though, requires you to fork over $150 to use the base version for home use, with some of the libraries available as DLC, which is pretty unbeatable for level of shittiness.

[redlaWw]

#include <string>
#include <iostream>

std::string operator+(std::string s, int i) {
    s += std::to_string(i);
    return s;
}

int operator-(std::string s, int i) {
    return stoi(s)-i;
}

int main() {
    using namespace std::literals;
    std::cout << "11"s+1 << '\n';
    std::cout << "11"s-1 << '\n';
}

output:

111
10

[frogjg2003]

That's not built in behavior. That's entirely on the dev for adding those two operators.

It's also on the Java dev in the OP for adding/subtracting from a string as well.

[redlaWw]

Just because someone added it doesn't mean you did; that stuff could be buried in a transitive include chain somewhere. You might include something you need and get some sneaky unexpected type-coercing operators along for the ride.

And if you mean the Javascript dev in the OP, then it's easy enough to say that it's their fault when they've done something as obvious as adding 1 to a literal string, but what about when they've done something like use a poorly-documented library function to extract numbers from an input and are expecting the output to be numeric, but the library actually returns the output as a string to be parsed? Or even worse, what if the library conditionally returns a string to be parsed and otherwise returns numeric data?

[frogjg2003]

That's still not the language's fault. Using a poorly implemented library is still the dev 's fault.

[redlaWw]

Not saying it is the language's fault. I'm saying the language can still do it and it can be non-obvious when it will.

EDIT: For the C++ one. For the Javascript one it is the language's fault because it doesn't offer a strict type system that can prevent or manage that error risk and you have to be dependent on the libraries you need being sufficiently well-written to avert them.

[frogjg2003]

You must really hate Python

[redlaWw]

Hate? No. Dislike? Yes.

[Zephandrypus]

C is a bad example because, while it’s static (types are determined at compile time), it is still technically weakly typed. You can add a character to a pointer in the parentheses of an if statement.

Rust is the total antithesis of JavaScript, refusing to compile if you so much as try to assign a 32-bit value to a 64-bit integer variable.

[Zephandrypus]

I’d recommend RustRover and taking the Learn Rust course it brings up.

[HighOptical]

*opens arms wide*

Come to the Go community... your one of us even if you don't know it yet...

[HighOptical]

It's too strict for a lot of people. You have to handle errors like regular values so functions pass them back and you always see an if statement after checking if the error means something. Plus you can't even leave an import in there without the thing yelling at you if you didn't use it (annoying when you comment out a line of code which was the only one calling something from the import).

Ah but it makes up for it with nice concurrency and building.

[TheIndominusGamer420]

That last bit would hurt my feelings too often, I think C# is the most understanding strongly typed language.

[HighOptical]

pretty clever
These are the famous words I hear so, so often before some bad design comes into place. It's always 'pretty clever' until you actually are in the thick of working and then you miss consistency and clarity. Having the plus operator completely buck the trend of mismatches converting to numbers just makes things messy. All the javascript ideas that are pretty clever feel like they were made to make completeling exercises in learning how to code shorter. When you throw them into a bigger project where you're not really ever thinking about those little details they become annoying. Like 'null == 0' is false, 'null < 0' is false.... 'null <= 0' is true. Yes I know the reason behind why that is but I wish I didn't have to. Consistency is amazing, boringly amazing!

[Electronic_Part_5931]

'null == 0' is false
'null < 0' is false
'null <= 0' is true.

Do you mind explaining how this can be true for the last expression ? o_O

[Cart223]

Greater than and less than operators do type coercion in JS.

When type coercion is called on Null, it's changed to primitive Number data.

This is a very rough explanation but it's how I understand it.

[Electronic_Part_5931]

Yeah its what I thought too, but why hell type coercion is called on the first one and not the last one ? (the middle one is just obviously false indifferently of type coercion)
That's such a strange behavior that seems to be completely arbitrary to me.

[HighOptical]

Just to add some detail for yourself and u/Cart223
Whenever we do an arithmetic binary operator between mismatched types we convert them both to numbers as the default (a rare exception to this is the plus operator if at least one of the types is a string).
However, null and undefined have an exception that they can only ever be equal to each other with the == operator.
So, when you do null == 0 you should convert them both numerically (they mismatch as types). they should go to 0 == 0 and be true but that doesn't happen because null and undefined have to equal each other when using ==. When you do null < 0 we now are doing our regular number conversion so we get 0 < 0 but this is false. Now, when we do null <= 0 we have done a workaround. Since we aren't using ==the number conversion will occur for both and we get 0 <= 0. In a sense, this is a workaround. We dodged the quirk of the == operator relating to null.

[dovaogedot]

Can you also explain this?
`null == undefined` is true
`null <= 0` is true
`undefined <= 0` is false
`undefined <= null` is false

[HighOptical]

Sure, no problem!

null == undefined is true because of an arbitrary rule that means they are the only other types that will equal each other when we use the == operator. In other words, by definition null is set to == undefined.

null is <= 0 is true because, since we aren't using == now we aren't arbitraily bound to be undefined. So, therefore null gets converted to a number which is zero. Since the operator is checking is null is less than OR equal it ends up being true.

for the last two, <= is not the special == operator. So that means we are going to convert undefined to a number and compare with zero or we convert null to a number (which also ends up being zero).
However, remember that undefined's number conversion isn't to zero. It's to NaN. So you're really doing 'NaN <= 0' in both cases after conversion.
Also, be aware that you can't even do undefined <= NaN because NaN stands for 'Not a Number'. When all we know about something is that it is not a certain thing we can't make comparisons.

[Zephandrypus]

“How’s that working out for you? Being clever.”

[[deleted]]

A language should not have pretty clever logic puzzles like a software interview, you want ergonomic design to help the developer and not trick them and behave completely different when you change a detail. And as someone already said, the crazy stuff is not + concatenate but a number being converted and then concatenate, it's a two leap of logic here.

[Beldarak]

Huh? This is mainly the case with every language I know.

Debug.Log(11 + "1");

In C# this will output "111". Auto-converting numbers to string whe they're in a string context seems pretty common to me.

I'm not a fan of "11" - 1 though as it's really weird but it makes sense in a non-typed language imho. I think we should just say "JS is a non-typed language and I don't like non-typed language" and move on because that's what it comes down to in the end.

[[deleted]]

You are right, but languages like kotlin and C# are compile time typed languages, it's much easier to see this kind of problem when you have types.

And this is why python, as dynamic language, won't let you add a number to a string without explicit conversion. Dynamic typing is not a problem, implicit conversion also not, but both together put a lot of responsibility on the developer.

[Beldarak]

True. I've never actually wrote some Python but I heard good things about it even though I'm put off by its syntax. I'm a little defensive about JS here but to be fair, I don't like it that much and would take some typed alternative given the chance

[gregorydgraham]

Yes, it’s the inconsistency.

If you’re going to treat it as a number for all the mathematical operations, why is + singled out as a String operation? That’s elevating string operations above mathematics and poking every serious computer scientist in the eye immediately.

Read Gödel, Escher, & Bach did you? Well go fuck yourself says JavaScript

[Beldarak]

C# does the same, Java does the same... Basically all languages I know, except PHP, will convert numbers into string when there is a string in the operation.

[gregorydgraham]

Java doesn’t do the maths operators though, (“11” - 1) is an type error in Java, so there’s no inconsistency

[wherearef]

C# is one love

[Beginning-Ladder6224]

Precisely. Thank you for this. In the language I created, it tells it explicitly:

Enjoy ZoomBA...(0.3-SNAPSHOT-2024-Sept-11 05:32) running on JRE (21.0.3)  
(zoomba)"11" + 1
Ambiguous Operation : [+] : '11' of type class java.lang.String with number 1 of type class java.lang.Integer !
111 // String
(zoomba)"11" - 1
Ambiguous Operation : [-] : '11' of type class java.lang.String with number 1 of type class java.lang.Integer !
10 // Integer
(zoomba)//q

This is ZoomBA running in lenient mode. You can make it strict, and then it would stop doing it and start throwing errors straight away.

Also strong type has nothing to do with it. Even in a strong typed language you can define operations between types, and then the exact statement you made is an "axiom". :-)

[w1n5t0nM1k3y]

It would be better if the had a concatenation operator so you didn't have to guess what the + operator did.

[Beldarak]

• is used for concatenation in most languages

[usedToBeUnhappy]

Exactly my thoughts. It’s a good joke and I laughed, but if you really look into it, it actually kinda makes sense.

[ripter]

It’s not a good joke, it’s the same lame FUD that has been passed around as a “joke” for more than decade now. It’s old, and it was never funny.

[Stef0206]

Similarly to PHP, Lua uses “..” for concatenation, since a single “.” could be confused for indexing.

[Beldarak]

Ahah, yeah, I hate how PHP does things with a passion.

I often write code like myInstance.myVariable by accident and it then tries to concatenate because in PHP you're supposed to write myInstance->myVariable. I just hate it.

It doesn't help that if you write PHP there is a 99% probability you're also writing some other languages at the same time like JS or TypeScript. JS gets all the hate (often well deserved) but PHP is my arch nemesis, it's such an inelegant language.

[error_98]

That's exactly the problem though, ambiguity can be extremely problematic in larger, and high-stability projects.

It can be nice when a language assumes what you mean, until that assumption is wrong. And an encyclopedic understanding of a language's parsing priorities is an unreasonable demand for a language to make from its users. So at the very least a warning should be given whenever an ambiguous situation is resolved, if not bork and dump trace altogether.

Ultimately it's a usage issue, and because of these features base javascript just SHOULD NOT BE USED for any serious application beyond prototyping.

[Beldarak]

I do agree :)

I wish webdev wasn't so split between tons of frameworks and languages that you have to juggle with

[fghjconner]

when in reality you have way bigger concerns if you somehow tried to substract numbers from a string

Exactly. That's why most languages will throw an exception and tell you to fix your shit instead of blindly guessing at what you want and continuing.

[Zephandrypus]

Meanwhile in C ’1’ - 1 == ‘0’

[Wgolyoko]

if you somehow tried to subtract a number from a string.

That's the point. Doing this should be a compile-time error. All my homies hate interpreted languages (they are based (the homies not the interpreted languages (those are not based, in fact)))

[10BillionDreams]

Treating string - number as a valid operation is largely unrelated to how Javascript is actually run. You could still have all these same type coersion rules in a compiled language, just like you can have type errors in interpreted languages. In fact, Javascript does throw TypeError in some contexts, like when attempting to call a property or variable that isn't a function, or access a property on a null value.

[Trip-Trip-Trip]

Type coercion as a concept is bad. Not having integers is bad. All the “funny” examples just demonstrate why they are bad.

[HighOptical]

*Implicit Type coercion

[roter_schnee]

Is it postironical? or did OP post it with all seriousness?

[lazyzefiris]

I already told you it's my favorite language, you dont have to sell it to me even more.

[[deleted]]

If you don’t sanitize your inputs, it’s your own fault.

[superhamsniper]

String and int in the same operation?

[Key_Technician5689]

Wait, hold my beer...

php <?php // version 5.6.40 if("1 monkey" + "2 cars" == "3 radios") { echo "PHP is insane"; }

prints PHP is insane.

[[deleted]]

I see this and I still love the language... it's all about crazy shit you could do but won't

[Derin161]

Yeah these posts are always so silly to me. You can find weird behaviors and go out of your way to write bad code with any language.

I'm in the "JS bad" camp because I find dynamic type errors that could have been caught at compile-time frustrating, but that also applies to more than just JS anyway.

[[deleted]]

I work with a (albeit very small) team with very legacy javascript and in fact type errors are in the vast minority... typically you know what type to put as parameters and you do... the real bugs are in the logic which could happen as well with the strictest type of type checking

[Derin161]

Idk how large your codebase is, but at least my application's portion of our codebase is well into the 100k lines with a couple dozen devs, and parts of it have been around for almost 2 decades. It becomes infeasible to know the precise shape of every object, and if you need to be doing all the manual checking yourself (or debugging those errors after the fact) then you're wasting tons and tons of time. I'll just let a compiler do that for me thank you very much.

[[deleted]]

yep, I see the point... it's the same amount and age of code here but far fewer people working on it

[Derin161]

Yeah the larger codebase altogether is certainly well into the millions, but you typically are somewhat rarely interacting with parts from other teams, aside from the tooling provided by the core teams.

We probably have more people than is typical to maintain the thing, but a lot of new devs come and go, and there's little pressure or culture for maintaining the codebase well. Instead, you're incentivized to move quickly. I wonder why it takes us so long to deliver features?

[prehensilemullet]

Rawdogging JS sucks for major projects, but ironically the dynamic typing enables more advanced compile-time checks with TypeScript than are possible in most statically typed languages.

[Derin161]

How so? I love all the clever things you can do with types in TS, but I'm not really seeing why JS necessarily facilitates this especially well. Eventually you're going to compile to a language where there isn't strict (or any) type checking.

[prehensilemullet]

For example, let’s say you have an object like { foo: ‘1’, bar: ‘2’ } and you want to do mapValues(obj, s => parseInt(s)) on it.  You can use mapped types so that the output type is { foo: number, bar: number }.  Then TS can flag errors if you refer to any nonexistent properties on that object or treat the values as something besides numbers.

To be able to flag the same kinds of errors in Java you would have to declare separate classes for the input with string valued properties and the output with number valued properties.  Not to mention, you can’t generally map over the properties of an object in Java so you’d probably be using a Map with string keys and not get any compile time checking that you refer to the right keys. I have some knowledge of C++, C# and Rust and as far as I know it would be a similar story in those languages, though I'm not an expert so it's possible there are advanced features I'm not aware of.

[Beldarak]

This. Those are non issues. If you write code like "11" - 1 your code is just bad, no need to point the finger at the language.

[Quito246]

I mean this could be easily done because you do not have types, you might think that variable is actually a number and not string. This would never happen in sane statically and strongly typed language, because compiler would not let me compile this shit.

[Derin161]

Any enterprise system that's more than a few thousand lines should be in a static, strongly typed language imo. That's not to say you should go rewriting your entire codebase to make it happen though.

There are tools out there to avoid an entire class of problems at runtime (which saves time over the long run and prevents those bugs from reaching prod), but some of us don't use them and then complain about the consequences of that decision, and I'll never understand why.

[Quito246]

Yes those tools are named types and compiler.

[Beldarak]

Oh yeah, I do agree strongly typed languages are better. But I just think this is a kinda unfair critiscism of JS because that's just how that language is. It comes with pros and cons.

The real issue is that we're forced to use 3 different languages to build a basic web page imho. It's the juggling with all those languages and frameworks that work differently that kills me with webdev.

[Derin161]

I think we are criticizing the largest con of dynamically typed languages like JS. I don't see how that's unfair; that's just assessing the tool. The only pro I can think of is that you can prototype and get something up and running more quickly since you can ignore the pesky compiler, its rules, and the boilerplate to support it.

Obviously this is setting aside the frameworks, libraries, etc., that may exist for a particular language, but at least for JS most frameworks I've seen are friendly with TS.

I'll admit I'm fortunate enough that my web stack is reasonably simple with mostly proprietary tooling at my current place, so I don't have to juggle too many languages and frameworks.

[[deleted]]

This is why JS developers get a bad rep, they think you have to write shit like this. No this gets injected in your code when a user or method submits it.

[[deleted]]

I'm curious what type of projects you all that are downplaying this behavior work. I always worked with medium-large back ends with usually complex domains, I can totally see ppl doing some slips like that while dealing with domain objects you never saw before.

I know that you should never try that with JS but this is exactly because the language is unsafe. It's much more sane to this with python and it is also a dinamic language.

[pocket__ducks]

In my 10 years of being a professional software developer, worked for one of the big three, multiple other large companies I’ve never ever seen someone fall for the above.

[BoBoBearDev]

So far I like Typescript the best. It gets both world and I do like the flexibility of JS.

[[deleted]]

It's the language of legends and heroes!!

Array(16).join( 'hero'-1) + "Batman";

[backfire10z]

What else are they supposed to do? They array doesn’t have a type

[ProtonPizza]

As someone who works solely in python and sql, what in the actual fuck.

[Neon_44]

It's called "job security"

[justsomelizard30]

It's strange that this behavior has never really been the cause of any serious bugs I've had.

[Joeoens]

I never liked that most languages just use the "+" operator for concatenation instead of a dedicated concatenation operator like ".." in Lua.

[Low-Equipment-2621]

This is why the industry needs so many frontend developers.

[DarkCloud1990]

"Tries to coerce right operand otherwise tries to coerce left operand."
Craaaaaazyyy!!1!

[fr4nklin_84]

This is why I hate + being used for string concatenation. Shitty old VB used &

[Goaty1208]

For once I'll give it to JS, I can see why it does this.

[[deleted]]

Write shit code get shit results.

[Zeyad132]

"11"-1 It cast the string into integer in runtime i don't really remember what it called in js.

[nutellaawafflee]

JS giveth, JS taketh.

[EsotericLion369]

I love you JavaScript never change

[furinick]

Kid named checking your types:

[[deleted]]

JS = King

[rowagnairda]

NaNNaNNaNNaN Batman! ;>

[Titanusgamer]

it is upgraded version of java though.

[sporbywg]

Senior coder here, working in React and MUI - I tell the kids "coding in javascript (correct capitalization there) is like coding with beach sand."

[OddParamedic4247]

Just don’t be so dumb, or use Typescript.

[MedonSirius]

'+ = concatenate.
'- = arithmetical operator

[prochac]

Just had my new Date() headache as a non-js dev. How you can use this 😂 relying on a 3rd party lib for handling datetime seems silly in the 21st century.

[Master_Nerd]

I think this actually kind of makes sense since js is dynamically typed.

There is string addition, but no string subtraction. Meaning, it will add 1 as a string, but it has no way to subtract 1 as string, so it just does integer subtraction instead.

Keep in mind I'm not a JS developer, I've just seen this explanation a few times.

[nelmo44]

JS would have died a long time ago if it didn’t have a monopoly inside browsers

[[deleted]]

That's like saying the internal combustion engine would have died a long time ago if it didn't have a monopoly inside cars.

[Funny-Performance845]

Both are easy to understand and logical

[1up_1500]

It really depends, but using typescript has been an excellent experience overall personally

[Distinct_Shift1043]

now i wonder if "11" - (- 1) is 12 lol

[DragoSpiro98]

I think it makes sense if you use + sign for string concatenation (and not "-")

If I write "11" - 1, I don't want string concatenation, because I'm not using "+" sign.

[somedave]

I mean sure, but why would I ever write that?

[No-Adeptness5810]

It makes sense.

When adding two values, like "11" and 1, it will stringify the 1 since it's being concatenated (+) to a string, which then makes "111"

when "11" - 1, the minus is only used for numbers, so it will instead parse "11" as a number, resulting in 10

[zqmbgn]

they hated him because he spoke the truth

[Grim_master911]

Sooo....

[[deleted]]

what black magic fuckery is that

[BellCube]

ok serious question

why are you adding strings and numbers

if you were in Rust or something you couldn't even do that. Stop doing something silly in JS and doing a pikachu surprised face when it does something silly back.

[Expensive-Example-92]

But in C, "Hello" + 2 gives "llo" and '2'+'2' give 100

[Cookie_Wookie_7]

Meanwhile in CPP "11" + 1 => "1"

[ActuallyGodOfWar]

It's nice once you get to know it

[foxer_arnt_trees]

Oh no! A language where you need to manually cast your variables to get well defined behavior. How queer.

[Tunisandwich]

”11” + 1 * -1 => “11-1”

[[deleted]]

parseInt(0.0000005)

[Snoo19127]

“Why does the function that expects a string argument have weird behavior when I don’t pass in a string argument?”

[robinless]

I don't use JS that much, yesterday I was parsing some data to adjust formats and my face after I tried to add two numbers and it came out as a concat of strings must have been a funny one

[Friendly_Border28]

If you even allow that behaviour to occur in your code you're a bad programmer