Why I sometimes hate JavaScript
geekregator.com
geekregator.com
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...
There was an article here a while back about "tabooing your words"[0], and I think it applies very well here. Instead of talking about just "Javascript", let's try to not mention it. Say "Ecmascript 5 without any tooling," or "ES 6 with 6to5", or "Ecmascript 5 with a linter", or "Ecmascript 5 in strict mode with a linter."
Suddenly, you will find that everyone in this thread agrees: "Ecmascript 5 in non-strict mode, without special tooling" is a shitty language for humans to write because mistakes so easily go unnoticed. And humans make mistakes.
And if you do use linting, or whatever, no need to feel offended: we're not talking about that language!
In essence, saying "the linter would have caught this" is like saying "Typescript doesn't allow that". It's completely true, but it's a different language.
The author was not talking about "Javscript", but about "Ecmascript 5 in strict mode without tooling." And I think we can all agree: that language is problematic.
[0] https://news.ycombinator.com/item?id=6855568
EDIT: Author was talking about strict mode. Still problematic.
It was in strict mode. It allows that.
But you're totally right, use strict is not syntactical. (I think?)
In another language the compiler/parser may have thrown a warning, but the issue here is actually that this is valid Javascript. Poorly composed Javascript, but completely valid.
Of course, jslint will complain about it (and a dozen other style things), so the more people utilize tools like that, the better.
More than anything, it's yet another reason to employ unit testing. Valid code that fails is very hard to debug without unit testing.
if (x = true) {}
Not to mention that that large a block of addition is bad code smell to me.
1. Assignments in conditions could be required to be surrounded with an additional pair of parentheses, like this: `if ((x = true)) {}`. GCC with warnings already requires this for C.
2. The assignment operator could be something other than the equal signs, for example, it could be `:=`. Assignment is so different from mathematical equality and beginners to programming trip up on this all the time, it's a shame programming languages copy each other for familiarity and keep this bad design.
3. Assignments in conditions could be banned out right, like Python does.
IMO, the really annoying language faults are the sort of thing that can't be fixed by a simple linter: object keys being converted to strings, the wonky pseudo-classy prototypal inheritance, dealing with libraries that abuse Function.toString or eval, etc.
Imagine a language were assignments were only done via := and comparisons with = or ==. A programmer would never encounter this error.
Modern Ada's a thoroughly nice language; I did a writeup: https://cowlark.com/2014-04-27-ada
12,40: Expected an assignment or function call and instead saw an expression.
The OP is talking about catastrophic errors as a means for surfacing problems in code. That's a pretty old-school (and I don't mean to pick on the OP, he mentions his background in the post) methodology for quality control in code. It worked a lot of the time in compiled languages because they're far more syntactically strict than languages like Javascript.
And that's why we need tools like jslint/jshint. Whether that's a good thing or not depends on your comfort with the language - having the flexibility to structure code differently can be seen as a positive, but you do open yourself up for these types of errors.
In Sublime text 3, you can have inline warnings and as-you-type linting with the sublimelinter jshint plugin:
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/concatenating with +, and the list goes on.
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.
When there are no semicolons between statements, it will automatically and silently insert them. Without this behavior his mistake would've been a compile-time error and easily caught. (Of course, this leads to the bigger bug that sometimes Javascript will insert them in the wrong place.)
He doesn't know exactly what the bug in Javascript is and how to point it out accurately, but he is absolutely correct that there is a bug in Javascript's design.
The problem is that the code is written in a way that makes it vulnerable to an implied semicolon.
The core syntax of JavaScript won't be changing any time soon, so it's important to teach beginners how to write code that minimises mistakes like these.
I haven't seen many books and tutorials attempt this. So it's unfair to blame beginners when there's so little encouragement to learn a strong defensive coding style.
jshint is nice for basic sanity checks, but it can't deal with bigger structural or stylistic mistakes. You can only fix those by learning from strong examples of good, clean code.
I think this applies to all languages. Being able to solve a problem and write a solution in code symbols isn't enough. I wonder if it would help everyone if there was a store of established best practices with examples for every language.
Javascript's automagic semicolon is that, and you're the kind of person who condones it.
Yes, at the end of the day one has to learn how to deal with the automagic semicolon, if one doesn't just give up on Javascript wholesale and finds a way to write better languages. However the very presence and behavior of that code in every javascript interpreter is still a cruel misbehavior whose implementation was a mistake. It is just as cruel and as much of a mistake to imply even in the slightest way that it isn't.
The correct response is to not blame the coder who stumbles over that, but to gently let them know that yes, Javascript is a bad language, and to gracefully show them how to not fall into that trap.
I wasn't blaming the coder or the language.
I was saying that it would help everyone if there was top quality online help explaining how to code around language deficiencies - the kind of deficiencies that everyone has to deal with it, because no language is perfect, and most languages are quite a lot less than perfect in at least some respects.
Be realistic. js isn't suddenly going to be rewritten with a proper semicolon patch. It's too established, and it would break too much code.
So complaining about it is a waste of everyone's time. It's like complaining about the fact that sometimes it gets cold in the winter.
It's more productive to do something practical about producing quality code that minimise possible problems, surely?
However, your first two lines were still:
> the implied semicolon isn't the problem.
> The problem is [...] the code [...]
Which is simply not an acceptable thing to say. The first thing to do is admitting that the language is the problem, not the coders or their code. The second thing is, now they're listening instead of being disgusted at you, to tell them solutions.
JS is a popular because runs on browser by default.
There are tools to make up for these language deficiencies, but our attitude to those bitten by the language deficiencies it's truly unfortunate.
Even Python, everyone's second favorite dead horse for dynamically typed language problems, would throw an error here.
"It's not the language's fault; it's your fault for not using all the tools and best practices that make the language tolerable!"
That, to me, sounds like the language has some deficiencies.
Normally I'd toss in a jab about deficiencies in choosing your language, too, but Javascript gets a bit of a free pass here on the browser.
But the implicit requirements in tooling, the fact people are blaming a developer for using the language without also relying on third party tools, tells me a lot about the language's deficiencies. Also a bit about the language's community.
Personally I've never understood with Javascript strict mode doesn't make semicolons mandatory.
It's not an excuse, of course.
Now I find myself wishing there was a stricter mode. <script type="text/sensible-javascript">, perhaps...
This feels to me like I'm constantly operating in some kind of gray area where everything is "correct enough". 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.
This bug most definitely should'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.
If your function is over 10 lines, it's probably bad, just look at your functions. Every 10+ line function I've ever written was only that long because of laziness and reducing them has always resulted in better legibility.
>I recently wrote some code for Class::Sniff which would detect "long methods" and report them as a code smell. I even wrote a blog post about how I did this (quelle surprise, eh?). That's when Ben Tilly asked an embarrassingly obvious question: how do I know that long methods are a code smell?
>I threw out the usual justifications, but he wouldn't let up. He wanted information and he cited the excellent book Code Complete as a counter-argument. I got down my copy of this book and started reading "How Long Should A Routine Be" (page 175, second edition). The author, Steve McConnell, argues that routines should not be longer than 200 lines. Holy crud! That's waaaaaay to long. If a routine is longer than about 20 or 30 lines, I reckon it's time to break it up.
>Regrettably, McConnell has the cheek to cite six separate studies, all of which found that longer routines were not only not correlated with a greater defect rate, but were also often cheaper to develop and easier to comprehend. As a result, the latest version of Class::Sniff on github now documents that longer routines may not be a code smell after all. Ben was right. I was wrong.
Of course I wouldn't have written that blog-article then, and wouldn't have gotten onto the HN homepage... Oh, well... :)
What is actually being done with the calls after the chain of +'s?
Edit: Something to do with semicolons being optional in js?
It tries to parse a newline with no semicolon as continuing the current expression, if it can't, it inserts a semicolon.
It's a 'feature' that's caused too many bugs and is a warning in most linters.
1;
2;
alert("returns undefined");
confirm("return true or false?")
(function() {return 3})();
(function() {})();
If the first couple of results were numbers or booleans, they would be summed:
> true + 10 + " result"
11 result
> [true,10," result"].join('')
true10 result var values = [];
values.push(phraseValue( result, queryData ));
...
var value = values.reduce(function(prev, next) { return pre + next; });
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'm happy that JS is getting this.
All to find in the end that I had used ( ) instead of [ ] (or maybe it was the other way 'round?) in a thick spot of code, and Javascript was happy to try to do that without throwing any kind of error.
That sort of thing happens in all languages to some extent, but debugging in Javascript is unmitigated hell.
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 "doing things manually" like this, as its easy to overlook such errors.
Does what you just said mean that we shouldn't talk about JS's weaknesses?
Or do you mean that we can, but that the points the author brings up have been beaten to death time and time again here on HN and this post + the inevitable comments it will attract have nothing to offer?
Those are the only two options I can think of for now. Or did you mean something else?
There are many totally lucid, on-point criticisms of Javascript and at least once a day the language ticks me off, but this one is not so black-and-white.
Also, I think you are looking for typescript.