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.
Why I sometimes hate JavaScript
51–60 of 66 posts
Re: Why I sometimes hate JavaScript
#52Good programmer, bad programmer. Good code, bad code. Let's not all pretend we don't have stupid bugs in our code regardless of editor, linting or language. 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…
JS is a popular because runs on browser by default.
Re: Why I sometimes hate JavaScript
#53Re: Why I sometimes hate JavaScript
#54I 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.
Re: Why I sometimes hate JavaScript
#55Good programmer, bad programmer. Good code, bad code. Let's not all pretend we don't have stupid bugs in our code regardless of editor, linting or language. 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…
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.
Re: Why I sometimes hate JavaScript
#56Re: Why I sometimes hate JavaScript
#57The real issue here is it's not an error. 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.…
This is like the if (x = true) {} kind of error. Yeah it sucks, but it's not really the language's fault. Not to mention that that large a block of addition is bad code smell to me.
Imagine a language were assignments were only done via := and comparisons with = or ==. A programmer would never encounter this error.
Re: Why I sometimes hate JavaScript
#58Good programmer, bad programmer. Good code, bad code. Let's not all pretend we don't have stupid bugs in our code regardless of editor, linting or language. 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…
As someone pointed out, the implied semicolon isn't the problem. 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 s…
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.
Re: Why I sometimes hate JavaScript
#59Earlier quoted context omitted.
Agreed. "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.
These two things are not exclusive. The language can be deficient, and you can be irresponsible not for using well-known, long-established tools for addressing those 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.
Re: Why I sometimes hate JavaScript
#60Earlier quoted context omitted.
This is like the if (x = true) {} kind of error. Yeah it sucks, but it's not really the language's fault. Not to mention that that large a block of addition is bad code smell to me.
Yes, it is the language's fault. The language could have been better designed, here are some solutions: 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…
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.