[_hardwaregeek]

I'm starting to develop a theory that a person's stance on JavaScript reflects their ability to critique reasonably and therefore their maturity as a developer (to an extent).

JavaScript undeniably has some problems. It's also undeniably useful and eating the world. If you can hold both of these stances in your head and reconcile them into a nuanced opinion, then that's a great sign. If your viewpoint collapses into "JS sucks!!!" or "JS rules!!!" then you're not providing an opinion as much as a dogma, often one that is regurgitated from some other source.

I'm not saying that one should find JavaScript good or bad by the way. Someone who abjectly dislikes JavaScript but also understands its utility is quite useful. The creators of TypeScript, ReasonML, etc. all had to dislike JavaScript in some form. But they had to dislike it in a productive, nuanced manner.

[slimsag]

Replace "JavaScript" with anything and the theory remains the same: those who can articulate and declare nuanced opinions about software they have had to interact with to a reasonable degree are able to critique reasonably.

I dislike the idea that all opinions must be in the form of productive, nuanced statements about how exactly technology should be changed in the service of 'one true set of technology'

I think it's OK for people to declare they enjoy or do not enjoy a particular technology without signaling how exactly they would change it. It's also OK to ignore or accept others opinions of personal taste. That's one of the things that enables us to have many different programming languages today, and enabled us to have JavaScript instead of FORTRANScript.

[throwanem]

Whether or not someone can distinguish "I don't like thing" from "thing is bad" still serves as a useful indicator.

[_hardwaregeek]

That's true, but JavaScript is something especially controversial :D. I've yet to find a programmer who doesn't have some sort of stance on JS

Also yeah it is fine to say "I don't care for JS" sans explanation. But if someone were to ask why, it'd be reasonable to expect a list of justifications that had some nuance.

[orange8]

I'd say that controversy is in direct proportion to its ever growing widespread use.

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

― Bjarne Stroustrup, The C++ Programming Language

[primroot]

Which reminds of this story from the Zhuangzi. I hope it is not too irrelevant.

"Zhuangzi was walking on a mountain, when he saw a great tree with huge branches and luxuriant foliage. A wood-cutter was resting by its side, but he would not touch it, and, when asked the reason, said, that it was of no use for anything, Zhuangzi then said to his disciples, 'This tree, because its wood is good for nothing, will succeed in living out its natural term of years.' Having left the mountain, the Master lodged in the house of an old friend, who was glad to see him, and ordered his waiting-lad to kill a goose and boil it. The lad said, 'One of our geese can cackle, and the other cannot - which of them shall I kill?' The host said, 'Kill the one that cannot cackle.'"

https://ctext.org/dictionary.pl?if=en&id=2853

[namelosw]

The quote is almost true, unless he didn't quantify things.

Let's say Java and PHP both have a lot of users, but I guess Java receives less percentage of complaints per 100 people. (Just a random example, if you don't agree you can substitute the two languages to suit your own experience)

So to really understand the controversy, it probably makes more sense to compare $NumberOfComplaints / $NumberOfUsers.

[goto11]

The point is that the rate of complaints grows when a language becomes more popular. As long as only enthusiasts and hobbyists use a language, you get relatively few complaints, because these are people who actively chose to use the language. When a language become more popular, more people will be forced to use it, more mediocre people will use it, and its shortcomings will become more apparent on larger-scale projects.

[bryanrasmussen]

And this is why I have yet to hear anyone complain about Brainf*ck.

[jmchuster]

I would also state it as "hold strong opinions weakly or hold weak opinions strongly".

Unfortunately, though it requires experience to become mature, not all experienced engineers are mature. When you see problems with the tools that you have, do you rail against them because it's not what you want, or do you seek out alternatives and then build them when they don't exist?

[baddox]

Couldn’t it be that I realize that JS has some problems and is undeniably useful and is eating the world, and I therefore conclude “JS rules!!!”

In my view, it lacks nuance to suggest that saying something is awesome must mean that it has no problems. :)

[_hardwaregeek]

Yeah maybe "JS is best language ever!!!" is a better example. Or "JS is perfect!!!"

[mattgreenrocks]

This is the “only say cheerful things” argument. If you want to impose that at the threat point of “maturity”, then be my guest.

Don’t be surprised when any legitimate criticism just sort of dries up, however.

[willtim]

> But they had to dislike it in a productive, nuanced manner.

No, they fundamentally rejected JavaScript, enough to build a whole new language and set of tools. This was not a subtle dislike of a few aspects of it.

Personally JavaScript absolutely terrifies me, it's a semantic mess, the equality table is one such example: https://dorey.github.io/JavaScript-Equality-Table/

[namelosw]

First, it's easy to fix by just using ===.

Second, It's more of a blub programmer thing. From multiversal equality's perspective, almost every mainstream statically typed language is also a semantic mess - you can even compare int to a boolean with == in a statically typed language without having any type errors, despite the comparisons always return false and 99 out of 100 that's not what people meant.

[nyanpasu64]

In C++, you cannot compare unrelated types unless there's an implicit conversion or explicit equality operator (or something like that). In Rust, you cannot compare same or different types unless you implement PartialEq, and you can't compare an int with a bool. In Java, you can't use == to compare an int and a bool (both primitives).

[willtim]

Most mainstream statically typed languages use subtyping, that is why they permit equality comparisons of different (sub) types. But they should and do obey all the usual mathematical laws, associativity, transitivity etc.

[goto11]

It is trivially easy to avoid though, just use === instead of ==.

Most of the JavaScript wtf's are people getting confused by the implicit type conversions (like [] == ![]). If you ask for it, JavaScript will readily convert a string to a number or an object to a boolean. But if you don't like that, just don't rely on implicit conversions.

[willtim]

The average developer spends most of her time reading other peoples code, so avoiding having to understand == is a luxury most will not have.

[ComputerGuru]

I’m not a fan of loosely-typed languages in general, but isn’t that chart pretty typical for dynamically typed interpreted languages? I know PHP’s is a mess and I’ve seen comparison/equality horror stories posted to HN regarding even the venerable Python.

[Athas]

No, many dynamically typed languages do not perform implicit conversions: Lisp and Python are languages that do it better. They still have some subtleties (Lisp has the EQ/EQL distinction, not to mention a huge number of other quality operators in Common Lisp), but I see implicit conversions as a singularly bad idea in a dynamically typed language.

[kazinator]

Lisp certainly performs some implicit conversions in numeric computing.

   > (+ 1 1/10 3.0)
   4.1

In this example, since + is a function, it's part of its semantics.

There would be a lot of verbiage if arguments had to be coerced to all be of the same type.

In addition to numeric examples, there are situations where Lisp is forgiving/flexible. For instance in most cases, a symbol can be used in place of a function object. The symbol is resolved to a function through its function binding.

That can be regarded as an implicit conversion, or alternatively as polymorphism.

Yet another example is that Common Lisp allows some string operations on symbols.

   (string= 'abc "ABC") -> T

No conversion ever takes place in the evaluation, as far as I know, or the passage of a value (e.g. from a function argument expression into the argument). All these kinds of things happen inside specific functions according to their respective rules.

[untog]

Literally the next tab on that page shows you the results with the === operator, which is what everyone uses.

That you don’t know this shows me that you don’t actually understand JS very well. That’s fine! But don’t make and broadcast a judgement without doing the research.

[willtim]

> That you don’t know this shows me that you don’t actually understand JS very well.

I know about the === operator, but the original one still exists, as does all the code that was (and still is) written using it that needs to be reasoned about. That you think adding a non-obvious alternative to the language magically makes the problem go away, suggests to me that you are the one lacking understanding, not me. It was also just one example of many well documented issues with the language.

> the === operator, which is what everyone uses

Since you accused me of "broadcasting without research", I'd like to see the evidence for this claim. I just looked at the HackerNews JS and there's plenty of double equals in there.