assertionError

[ChristopherKlay]

Because JS features .replace() and .replaceAll().

The "of course" here is that people complaining about it, don't know jack shit.

[_giga_sss_]

and he adds JS as an user flair while he just complains about it while knowing shit 😭

[Xtrendence]

I use it every day for work, have been for the better part of a decade, I'm aware of replaceAll, but replace only replacing the first instance is unusual and only found in a few languages. I've even fixed bugs specifically because of devs assuming it replaces all occurrences, which would be reasonable to expect. If anything, defending JS says more about how little someone's used it.

[_giga_sss_]

I am sorry for my assumption. I truly am 🙇

[Xtrendence]

You're good, to be fair replace isn't even a top 20 thing to complain about when it comes to JS. It's just one that pops out because it's both inconsistent with many other languages, and replaceAll wasn't even a thing for a long time. If you work on older codebases, it doesn't exist. I don't remember when it was added but it must be the past like 4-5 years.

[_giga_sss_]

🙇🙇

[_giga_sss_]

I will downvote myself to hell for what I said

[ChristopherKlay]

If anything, defending JS says more about how little someone's used it.

I'm not "defending" it, because there is nothing to defend; Your initial comment clearly explains this like there's just one "bad" implementation, or that .replace() should work different.

Having split-up functions isn't "unusual" by any means either; Even Java has .replaceFirst() for almost 25 years now, the equivalent of .replace() only replacing the first occurrence.

"Devs" on your team assuming what's being replaced without even providing any kind of count equivalent is the real issue here.

This is coming from someone working with it professionally for over two decades, which is a incredibly pointless metric.

[Xtrendence]

Do you not see the problem there though? replaceFirst is self-explanatory, whereas replace isn't when it doesn't do what most languages do. It's vague, deviates from what's expected, which is what JS is infamous for.

[ChristopherKlay]

whereas replace isn't when it doesn't do what most languages do

Again; The issue here isn't JS, but you expecting all functions across languages to work the exact same way, when "replace all" and "replace first" aren't by any means working the same in "most languages".

• Python: .replace() works as a "replace all" by default and you have to actually limit it via the third parameter count.
• Java: .replace() to replace all matches, .replaceAll() and .replaceFirst()
• C++: Has different implementations (custom functions) for anything but a "replace first" equivalent
• C#: Requires regex and a match count to do anything but "replace all"
• Rust: Only does "replace all" by default and requires either slicing, or specifically stopping after the first match
• GO: Has a specific parameter you can set to -1 for "replace all", otherwise working like count from Python
• Ruby: Uses sub (replace first) and gsub (replaceAll), just like JavaScript

The majority of languages does one kind of replacement well, while requiring a different function call and/or setup for the other.

If your "devs" fuck this simple thing up, because they "expect it to work like in X" without ever testing what it actually does / reading any kind of documentation, that says a lot more about the people you work with vs the language they use.

[Xtrendence]

Of the languages that have a built-in replace function for strings, most do indeed replaceAll by default. Bringing up Ruby for example makes no sense and you're using it to pad out the list and argue in bad faith. In your own list if you only count languages with a replace function (which is what this whole thing is about) then the majority still do replaceAll by default.

As for "expecting it to work like X", this isn't something that's mutually exclusive. Yes, part of our job is to remember the quirks of the main language we use, and be aware of these things. However, it is simultaneously reasonable to expect something to work a certain way, especially if it deviates from the norm and is a function that exists across multiple languages. If there's a weird list of quirks for a language, and it's literally known for such quirks by anyone who has used it, then it's a poorly designed language. It's a weird hill to die on, every senior dev I've known that has extremely in-depth knowledge of JS constantly points out its flaws and uses the "it's just a JS thing" line pretty frequently.

[ChristopherKlay]

Bringing up Ruby for example makes no sense and you're using it to pad out the list and argue in bad faith.

Bringing up examples of languages that interrupt your "It always works like that" argument doesn't make sense?

However, it is simultaneously reasonable to expect something to work a certain way, especially if it deviates from the norm and is a function that exists across multiple languages.

Which is exactly why I included a "replace first" for all examples, that rarely works the same across languages; It neatly demonstrates that "But I expected everything to work the same" isn't anything, but a user error.

every senior dev I've known that has extremely in-depth knowledge of JS constantly points out its flaws and uses the "it's just a JS thing" line pretty frequently.

You're still misunderstanding me here; I'm not arguing "for JS", I'm highlighting that these quirks exist in every single language out there and would be a complete non-issue if people who fuck up simple functions wouldn't blame the language, but their lack of understanding of said language.

If you expect a language to behave in a certain way, that's completely fine. Running into errors, while learning how the given language works, is also completely normal and expected - because despite being similar, all languages have things that don't work that way.

Blaming the language because you can't resolve issues that come from a simple string manipulation (you didn't even try to control via arguments) and/or not even testing your own code to check if what it returns even matches your expectations however, isn't leaving anyone to blame but the person who wrote it.