Why I sometimes hate JavaScript

The &quot;JSlint catches this&quot; argument is valid, but not to defend JS. When you say: &quot;with a linter this doesn&#x27;t happen,&quot; you&#x27;re defending (Javascript + linter), not Javascript.<p>Just as when someone says: Typescript would not allow this, or that. Or use strict mode would not allow that. Yes! True. They would not. But they are not JS: they are Typescript, or JS strict mode, or...<p>There was an article here a while back about &quot;tabooing your words&quot;[0], and I think it applies very well here. Instead of talking about just &quot;Javascript&quot;, let&#x27;s try to not mention it. Say &quot;Ecmascript 5 without any tooling,&quot; or &quot;ES 6 with 6to5&quot;, or &quot;Ecmascript 5 with a linter&quot;, or &quot;Ecmascript 5 in strict mode with a linter.&quot;<p>Suddenly, you will find that everyone in this thread agrees: &quot;Ecmascript 5 in non-strict mode, without special tooling&quot; is a shitty language for humans to write because mistakes so easily go unnoticed. And humans make mistakes.<p>And if you do use linting, or whatever, no need to feel offended: we&#x27;re not talking about that language!<p>In essence, saying &quot;the linter would have caught this&quot; is like saying &quot;Typescript doesn&#x27;t allow that&quot;. It&#x27;s completely true, but it&#x27;s a different language.<p>The author was not talking about &quot;Javscript&quot;, but about &quot;Ecmascript 5 in strict mode without tooling.&quot; And I think we can all agree: that language is problematic.<p>[0] <a href="https://news.ycombinator.com/item?id=6855568" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6855568</a><p>EDIT: Author was talking about strict mode. Still problematic.

The real issue here is it&#x27;s not an error.<p>In another language the compiler&#x2F;parser may have thrown a warning, but the issue here is actually that this is valid Javascript. Poorly composed Javascript, but completely valid.<p>Of course, jslint will complain about it (and a dozen other style things), so the more people utilize tools like that, the better.<p>More than anything, it&#x27;s yet another reason to employ unit testing. Valid code that fails is very hard to debug without unit testing.

Jshint catches this with 2 warnings: missing semicolon and expected assingment or function call.<p>In Sublime text 3, you can have inline warnings and as-you-type linting with the sublimelinter jshint plugin:<p><a href="https://github.com/SublimeLinter/SublimeLinter-jshint" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SublimeLinter&#x2F;SublimeLinter-jshint</a>

Good programmer, bad programmer. Good code, bad code. Let&#x27;s not all pretend we don&#x27;t have stupid bugs in our code regardless of editor, linting or language.<p>JS is a mediocre language. It is popular because it is ubiquitous, not because it is good. It really does have bad error handling, weird optional rules, problems determining type when adding&#x2F;concatenating with +, and the list goes on.<p>His was a syntax error that could have been caught with linting, sure. But there is plenty of well-formed JS that passes linting but still behaves badly due to the language itself.

Lots of comments here, and on the blog, essentially stating &quot;It&#x27;s not Javascript, it&#x27;s that you forgot to [lint|test|format|.+]&quot;<p>There are tools to make up for these language deficiencies, but our attitude to those bitten by the language deficiencies it&#x27;s truly unfortunate.<p>Even Python, everyone&#x27;s second favorite dead horse for dynamically typed language problems, would throw an error here.

Optional semicolons is my biggest hate with Javascript --- combined with expression statements silently discarding their result, it makes this kind of mistake far too easy to make.<p>Personally I&#x27;ve never understood with Javascript strict mode doesn&#x27;t make semicolons mandatory.

I think this is a general problem for people used to the comfort of compiled languages. I also struggle with languages like JavaScript. I always have the feeling that I&#x27;m actually doing something wrong or non-standard but the webbrowser is smart enough to understand it anyway.<p>This feels to me like I&#x27;m constantly operating in some kind of gray area where everything is &quot;correct enough&quot;. But as others have already pointed out, this can be ameliorated by using the right tools. So the problem is actually purely about taste, I guess.

Honestly, there should have been a loop there. The author introduced un-necessary complexity and a bug appeared. Not that Javascript is a great language.

Sure, this is annoying, but the reality is that this type of stuff is very easily avoided through the use of linters. IMO, you should never work on a dynamic scripted language like JavaScript without constantly running a linter in the background to pick up stuff like this.

If you only hate Javascript sometimes, you are definitely new to the language. That said even in a proper language like Ruby this particular bug can happen, that&#x27;s why communities around these languages strongly encourage proper discipline, enforced by tools.<p>This bug most definitely should&#x27;ve made your tests go red, your linter give a warning and your code metrics suite should have a thing or two to about the huge expressions and 10+ line function they are in.

I really don&#x27;t see why this isn&#x27;t a syntax error<p>What is actually being done with the calls after the chain of +&#x27;s?<p>Edit: Something to do with semicolons being optional in js?

Whenever you can&#x27;t find the bug in javascript, I beg you to run the code through jslint. It would have caught this right away.

It&#x27;s way better to use [values].join(&#x27;&#x27;) here... It&#x27;s probably faster and it coerces all values to string.<p>If the first couple of results were numbers or booleans, they would be summed:<p><pre><code> &gt; true + 10 + &quot; result&quot; 11 result &gt; [true,10,&quot; result&quot;].join(&#x27;&#x27;) true10 result</code></pre>

My approach, in any language, would be to collect it in an array and sum (or concatenate) it at once.<p><pre><code> var values = []; values.push(phraseValue( result, queryData )); ... var value = values.reduce(function(prev, next) { return pre + next; }); </code></pre> I understand that COLLECTION.reduce may not be in all javascript implementations (or even in all languages), but that would be my first thought on how to handle that mess. Id probably even make it a function addAllOfTheseValues(result, queryData);<p>I also dislike direct string concatenation, I always try to use print type functions because it is easier to separate variables from text and spot potential errors. I&#x27;m happy that JS is getting this.

I had a similar-ish problem just last night. Spent over an hour crawling through some code trying to figure out why it wasn&#x27;t working like it was supposed to. I ended up doing the divide-and-conquer approach with &quot;console debugging&quot;. I was cursing wildly by the end of it.<p>All to find in the end that I had used ( ) instead of [ ] (or maybe it was the other way &#x27;round?) in a thick spot of code, and Javascript was happy to try to do that without throwing any kind of error.<p>That sort of thing happens in all languages to some extent, but debugging in Javascript is unmitigated hell.

Doesn&#x27;t JS have a join function?<p>I realize that problems like this are the reason that my coding is going in a more functional direction (I would still say I write imperative code), but I avoid &quot;doing things manually&quot; like this, as its easy to overlook such errors.

You&#x27;d spot that right away if you had a visual jshint&#x2F;jslint plugin in your IDE. It&#x27;s a real time saver to have one: there are dozens of cases like your example that are valid JS, although it&#x27;s not what you intended to write.

What Node.js taught me is that JavaScript is language like any other. It has good parts, it has quirks and you have to know what are its strenghts and what are its weaknesses to use it properly. And you can say that about any other language.

I agree that JSlint would catch this, but then againg that doesn&#x27;t seem like a valid argument to defend JS in this specific subject.

JSHint is a thing.<p>Also, I think you are looking for typescript.

That title looks rather backwards to me. You don&#x27;t need a reason to hate JS. You do need a reason to not hate it.

I&#x27;ve spotted the error in less than 5 seconds... + I personally don&#x27;t like the way you write code.

I saw the error in 30 secs. Advice: try to use dislike instead of Hate.