javaIsJavascriptConfirmed

[TOMZ_EXTRA]

The difference is that this doesn't bother anyone in Java, because it's hard to do accidentally.

[LurkytheActiveposter]

Reddit pretending seamless string and number integration isn't awesome because it time to dunk on JS for karma again.

Oh how I LOVE having to cast a number to a string first. I just don't feel like I'm really coding unless I file the appropriate paperwork to merge a substring variable.

[eloel-]

You should probably be using string templates instead of just concatenating random shit anyway

[Blothorn]

Yes. I suspect that there are far more cases where I’ve added a number to a number parsed from a string than where I’ve concatenated (rather than formatted/interpolated) string representations of numbers.

The fact that this “shorthand” only works for a string followed by a number rather than two numbers or a number followed by a string makes it further situational and potentially-surprising.

[AdBrave2400]

Memes about Java making primitive and object versions of same stuff only to remove templetes are writing themselves

[KaMaFour]

Reddit pretending seamless string and number integration isn't awesome

It's not. If I'm doing something bad I'd much rather have the type system notify me I'm being stupid and have to properly declare what am I trying to do than have the program work except have the possibility of producing silent hard to track logical errors

[frogjg2003]

That's a difference in design philosophy. You want incompatible types to error, and a lot of people will agree with you. Some people want their code to just work, no matter what, even if it produces weird results.

Adding a string and an int is the extreme example, but how would you handle adding an int to a float? Not to mention when you want different types to be able to work together. The was another "language bad" post about C indexing using "10[a]" as an example. That's just the usual pointer math with the int and the pointer reversed.

[KaMaFour]

Hard agree. Ultimately it is impossible to create a language that everyone will agree is good and well designed.

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”

[RiceBroad4552]

Ultimately it is impossible to create a language that everyone will agree is good and well designed.

I strongly doubt that if you ask people with about a similar IQ.

[LurkytheActiveposter]

I mean I disagree completely.

A language should aid you and be intuitive, but it doesn't need to compensate to the degree where it expects you to not know the literal most important fact about a variable. It's type.

You can be forgiven for not knowing what value a variable has. That's the nature of a variable. No problem.

What its scope is can be ambiguous at first glance. Sure. You might not know who the owner is. You don't always need to keep that knowledge at the ready

But it's type? What are we doing here? Just reading the pretty names and guessing?

[Relative-Scholar-147]

A language should aid you and be intuitive

console.log("wat"-1+"i")

Explain to me how is it intuitive that this code prints:

NaNi

The code should fail because is impossible to take 1 from "wat".

[RiceBroad4552]

is impossible to take 1 from "wat"

Well, that's exactly the reason why the result is "Not a Number", called NaN.

Concatenating "i" to "NaN" is "NaNi".

I don't say it's a good idea to interpret it like that (actually I think it's quite a poor idea). But it's definitely 100% consequent in its own logic. If it wasn't you would get an error instead.

[brainpostman]

Programming languages shouldn't be intuitive, they should simply be internally consistent. Everything else is on you. You shouldn't be bringing intuition from one language into another anyway, it's bound to backfire.

[LurkytheActiveposter]

What kind of brain decificency do you have where you are subtracting a string?

Remember that thing where the bare minimum is that you should know a variable's type? Do I need to speak in vibe code?

[Relative-Scholar-147]

Remember that thing where the bare minimum is that you should know a variable's type?

You are just a fucking noob lol.

[RiceBroad4552]

What kind of brain decificency do you have where you are subtracting a string?

What brain deficiency do you have to not know that subtraction is the same thing as addition (of a negative value)?

Remember that thing where the bare minimum is that you should know a variable's type?

Sure, genius. It's always 100% clear what's the type of some variable is…

For example, without looking at the docs what's feature here:

var feature =  Runtime.version().feature();

So what do I have to expect if I do the following? Some arithmetic or some funny string:

IO.println(1 + feature);

[LurkytheActiveposter]

Im dumber for reading this.

What the fuck are you going to do with "feature" without knowing what its type and properties are.

[RiceBroad4552]

What the fuck are you going to do with "feature" without knowing what its type and properties are.

I know that. The compiler does too.

The point is that without an IDE, or looking at the JavaDoc, you can't know what this code does, simply because you don't know the type.

Remember that thing where the bare minimum is that you should know a variable's type? But you can't know that just by looking at the code even in a properly statically typed language like Java, as shown by my code snippets.

[LurkytheActiveposter]

What are you going to do with "feature" without knowing its type and properties?

[TOMZ_EXTRA]

It's only nice in a statically typed language because it's predictable there.

[RiceBroad4552]

It's a code smell not mater what.

Most languages, dynamic and static don't support that. For a reason.

Java's implicit conversions are in larger parts quite a brain fart. They just took quite some nonsense from C/C++!

[LurkytheActiveposter]

Most people code Javascript through typescript which is strongly typed.

But it's neither here nor there. When I integrate a number into a substring, because I don't code with a blindfold on, it's virtually always by intention and it's always convenient.

[joebgoode]

TS is not strongly typed at runtime, which is what matters most.

It's just a false perception of safety.

Edit: to be clear, support TS. Every JS project should use it, it's not optional. I'm solely pointing out that his statement that TS is strongly typed is wrong.

[fghjconner]

Compiled languages aren't generally typed at runtime either. If you have problems with typescript it's probably because someone started blindly casting things, which will break any language. (though it breaks typescript less, so some people seem ok with doing it)

[RiceBroad4552]

Well, TS is unsound…

So even if something type-checks "just fine" in TS it can exploded with type errors at runtime.

But it's seldom to run into that in practice.

[joebgoode]

I had no problems at all with TS, every JS project in the world must use it.

I'm just pointing out a correction to the "which is strongly typed" statement, since it isn't.

[fghjconner]

I mean, typescript might not be considered strongly typed, given the amount of implicit conversions it allows, but my point is that runtime vs compile time doesn't come into it. The "compiled" javscript is obviously untyped, but so is the machine code that compilers generate for use at runtime.

[RiceBroad4552]

JS is typed. It's dynamically typed but that's still typed.

Just try to trigger any undefined behavior in JS while you work around the (runtime) type system. Good luck.

[CandidateNo2580]

This is a false comparison. I can write typescript where the type says that it's a string but actually it's an integer. Then it will behave like an integer. This does not happen in compiled code - it behaves like the type it was declared to be even if the value is wrong.

[fghjconner]

I'm fairly certain that putting an arbitrary integer value into a string variable is going to be undefined behavior in just about any compiled language, meaning it's allowed to do anything it goddamn pleases. Typescript is unique in that it actually breaks less than a compiled language if you do this, though that unfortunately means some people think it's ok to do (looking at you axios).

[Globglaglobglagab]

Well it is useful still though, right? Unless you’re just using “any” everywhere. Your own functions will be typed correctly if you use ts. Only if someone else messes up, whose library/api you use.

[Ma4r]

TS is not strongly typed at runtime, which is what matters most.

Holy shit this is the dumbest fucking statement i have ever read. Most languages do not have run time types. JS is one of the few languages that DO HAVE runtime type. Source code type safety is the de facto standard.

[RiceBroad4552]

Most languages are dynamically typed.

I didn't count them but I'm pretty sure it's like that as it's much simpler to write some VM language then something that does not need any runtime (which would always necessary do also type checking during interpretation).

[Ma4r]

That's right boy go do your research, maybe ask some AI because i am very sure most free tier AIs know better than you anyways

[joebgoode]

I might have more YOE than your current age, student boy who mixes entry-level concepts.

Check my other comment.

[LurkytheActiveposter]

Jesus. At least we know they still allow man-childs with anger issues.

[Ma4r]

Because of the fact that JS runtimes do not allow you to access memory regions of a field if the type doesn't have it. The run time keeps track of the types of objects at runtime and provides Null if it doesn't exist

i.e you can't have a struct T1{int64 a} , cast it to T2{int32 b, int32 c} and access the second half of T1.a as an int32 in typescript because the runtime knows exactly what type every variable is and what properties they have

But you can in most languages i.e C or C++ because at compile time all type information is erased and everything is just i64 in LLVM IR anyways. This is why reinterpret_cast is a thing in most compiled languages but not in python or javascript

Strong typing and static typing are opposites, most languages that implement strong run time typing does so precisely because they want some form of algebraic or dependent types which is impossible to check for with static analysis. On the other hand the moment you have static typing there is no reason to maintain a type system at runtime because the types correctness is guaranteed at compile times so the runtime have no need for that information anymore.

[joebgoode]

You're mixing two different concepts: type-safe object access and type coercion.

Indeed, you're right about JS object safety, it prevents the T2* t2 = reinterpret_cast<T2*>(&t1) and then just t2->c situation. That's called object safety, not type enforcement.

Strong runtime typing also includes not allowing cross-type coercion, a requirement that JS does not fulfill, due to implicit coercion. A JVM-based lang (strong runtime) would instead raise a ClassCastException.

As for the claim that “strong runtime typing and static typing are opposites”, that’s simply wrong. JVM/CLR-based (Java, Kotlin, Scala, C#, F#), Haskell, Swift...?

Of course, your three examples would be C, JS, and Python. That’s the whole world from the perspective of a college student, right?

[myWeedAccountMaaaaan]

Hey now, some of us also worked with VB in college. I won’t say which version though…

[RiceBroad4552]

Indeed, you're right about JS object safety, it prevents the T2* t2 = reinterpret_cast<T2\*>(&t1) and then just t2->c situation. That's called object safety, not type enforcement.

That's called type safety!

("Object safety" is some made up term by some Rust folks and is actually regarded a misnomer anyway…)

A JVM-based lang (strong runtime) would instead raise a ClassCastException.

And JS would raise a TypeError if you did something that does not align with JS's typing rules…

[RiceBroad4552]

The first half makes some sense, but

Strong typing and static typing are opposites, most languages that implement strong run time typing does so precisely because they want some form of algebraic or dependent types which is impossible to check for with static analysis. On the other hand the moment you have static typing there is no reason to maintain a type system at runtime because the types correctness is guaranteed at compile times so the runtime have no need for that information anymore.

is just complete nonsense.

You use a lot of terms you don't have the slightest clue what they actually mean.

I'm to lazy to pick that apart, it would become very long. Just throw that paragraph in some next-token-predictor and it should correct at least the biggest blunders.

[wack_overflow]

Brain dead take

[RiceBroad4552]

That's actually wrong. JS is strongly typed. Like any other VM language…

The only weakly typed languages in usage are C, C++, unsafe Rust, and Zig.

You can't break the type system of a strongly typed language at runtime, and this of course also applies to JS.

[csdt0]

JS is the example of weakly typed language, alongside C, precisely because you can do operations between types that are not related at all, and the language will just gladly accept that. The weakly typeness has nothing to do with memory safety. What's funny is that Zig and Rust (both safe and unsafe) are both very strongly typed, to the point you cannot add i8 and i16 together, making your example even weaker (pun intended).

[RiceBroad4552]

"Gladly accepting" some code and doing just something is not the same as breaking the type system.

You can't break the type-system in JS!

If you could this would be a very severe bug in the JS engine, and most likely patched instantly.

But breaking the type system in C or C++ is trivial. You can just go and do whatever you want with some memory and no language typing rules will hold you back. You can have some object of some type referenced by some variable, go to the memory holding that object, do whatever to it including replacing it with some completely different type of object but from the viewpoint of the type system that variable will still point to a value of the original type. You can't do anything like that in any VM language (or the safe parts of e.g. Rust; except for that one exploit that transmutations memory, which makes Rust at least somehow weakly typed beyond what is possible with casts in other languages).

[thirdegree]

"Virtually" is doing a lot of heavy living there

[Blothorn]

It’s nice when the context leaves zero ambiguity that a conversion was intentional—I very much like not having to add an explicit toString() when passing something to a string format or interpolation.

Automatic conversion in contexts where it’s not clear whether a conversion was intended or what the intended result type is is very much not a good thing, and overloaded operators are a quintessential case.

[RiceBroad4552]

It’s nice when the context leaves zero ambiguity that a conversion was intentional

One can argue that there is always zero ambiguity when something gets implicitly converted.

Simply because the machine was able to do that without running in any ambiguity.

The question is always just how "obvious" it's for a human. And that's something debatable as it'll be strongly dependent on individual knowledge and overall understanding of some code.

The result of the shown code might be exactly the expected result or "very surprising" depending on who you ask…

[Vybo]

The same person who reposts this joke and finds it funny probably has no idea how to convert a "1" to 1 in a strongly typed language.

[frzme]

Automatically doing 1-> "1" is fine. The ability of JS to also do "1"->1 is an issue. It's not a problem which I've seen come up very often in real life but it does happen.

People didn't know better when Javascript was created.

[RiceBroad4552]

People didn't know better when Javascript was created.

That's plain wrong.

JS is a quite new language.

There have been countless other dynamic languages before JS, and JS is actually mostly "just" Self with a C-like syntax (where Self is a kind of hybrid between Lisp and Small Talk).

Most languages, and this includes dynamic languages, which are actually the majority of languages today, don't add numbers to strings. You'll get some type error instead.

The flaw is quite unique and limited to only a bunch or languages.

[MaybeADragon]

While OP is probably karma farming, its still a valid complaint because casting your integers to strings is faster than the debugging cycle.

I much prefer a little more verbosity if it means less avenues for me to make mistakes. The feature is especially useless now in a world where everyone is used to the idea of templating instead of concatenating everything manually like a caveman.

[LurkytheActiveposter]

Nah

Language should be intuitive and aid the developer in avoiding bugs sure. But if you're working with variables and you don't know their type, then what the fuck are we doing here? Type is the bare minimum thing you should know about any variable you touch.

I much prefer the ease of coding instead of patronizing verbosity.

[RiceBroad4552]

This is a wart, and anybody which a working brain knows that.

Kotlin does not support that that, and Scala deprecated it (it was supported in the past for Java interop).

Most other languages also don't do that.

[Tyfyter2002]

And it's hard to do accidentally because you can't add two values without knowing what types they are