Live data from Hacker News

On JavaScript's Weirdness

stack-auth.com

81–85 of 85 posts

Re: On JavaScript's Weirdness

#81
post #18

I can pretty confidently say that every article I have seen in the past 5 years that complain about weirdness of JavaScript is about things that you would never do in a modern, production-level codebase. Many of these issues are about pre-ES6, outdated practice (e.g. eval, using == operator) that are almost certainly going to be flagged by a linter. Very occasionally, you do get hit by some weirdness, but likely does…

If the language needs a linter to keep otherwise-competent developers from introducing potentially maddening bugs into the codebase, it's weird. JS was developed in a hurry and has been extended into doing things it was never meant to do, and it shows.

That's not really a useful way to think of it.

Javascript could not have been released perfect for all current and future uses. Thus it either needed to change or fall out of use.

It changed.

The linting is simply part of a migration mechanism that allows for the change to happen. Compatibility is maintained for existing code, while on-going and future development can avoid the bad/obsolete parts. It's not random that eslint has such fine-grained configurability -- it allows each code base to migrate at whatever rate makes sense for it.

So all this is simply a product of javascript's longevity, which itself is a testament to its utility and flexibility. You call it "weird" but it would be a damn shame if it wasn't as useful and flexible as it is.

Re: On JavaScript's Weirdness

#82
post #50

Earlier quoted context omitted.

In JavaScript, a 'let' inside the initializer of a for loop is captured by value, all the others are captured by reference. I think it's fair to call that semantics "implicit".

consider this for (let i=0;i console.log(i),30); i-=10 } Capture by value would print 10, 11, 12 that's the value when it was captured Capture by reference would print 0,1,2 It's much easier to conceptualise it as for (const i=0;i console.log(i),30); } which is fine because i never changes. It is a different i each time. fancier example for (let x = 0, y = 0; y console.log("timeout",x,y),30); x-=10; y-=10; }

> which is fine because i never changes. It is a different i each time.

This is clearly a super weird hack to make closure capture behave more like you'd want. There's a reason this level of weirdness isn't needed in C++.

Re: On JavaScript's Weirdness

#83
post #22

Earlier quoted context omitted.

I'm thinking Kotlin for my next backend project. Or maybe Unison ;)

I prefer Java because I know it better, but Kotlin is nice. I'd prefer it over .NET, which is still kind of messy unless you're doing some quite specific things where the multi platform efforts have actually succeeded. F# is fine for small tools and some CLI stuff, but big frameworky things tend to be a mess or MICROS~1 specific. Some people are likely to claim it's not the case anymore and so on, but it's my recent…

What are the things where multi-platform efforts did not succeed?

Re: On JavaScript's Weirdness

#84
post #18

I can pretty confidently say that every article I have seen in the past 5 years that complain about weirdness of JavaScript is about things that you would never do in a modern, production-level codebase. Many of these issues are about pre-ES6, outdated practice (e.g. eval, using == operator) that are almost certainly going to be flagged by a linter. Very occasionally, you do get hit by some weirdness, but likely does…

If you actually opened the article, I think you would find it interesting. I agree that a well-configured eslint catches 99% of the weirdness, but this article tries to be about the remaining 1%.

Yes, and the first one is eval, something that one should not use outside extraordinary situations.

Re: On JavaScript's Weirdness

#85
post #27
post #18

I can pretty confidently say that every article I have seen in the past 5 years that complain about weirdness of JavaScript is about things that you would never do in a modern, production-level codebase. Many of these issues are about pre-ES6, outdated practice (e.g. eval, using == operator) that are almost certainly going to be flagged by a linter. Very occasionally, you do get hit by some weirdness, but likely does…

You should have probably read the post.

I did.
Post reply on HN