Hacker News new | past | comments | ask | show | jobs | submit login

> typescript should still be the exception

And JS shouldn't be exceptionally bad but here we are, and people use TypeScript as alternative to stay sane.

I agree that modern web development comes with far too much complexity on average, but people started adopting those frameworks for a reason. The web is kept backwards compatible with obsolete standards which have been created in a different time for different purposes, and at some point it becomes easier to build abstractions over that. For example TailwindCSS adds another "compilation" step and configuration file but in return makes styling much more tolerable than standard CSS. Is it necessary? No, but when you build a large website all those little things add up.




Agree here. TypeScript is a bit of a Godsend even when using the vanilla DOM API because (a) the DOM API uses so many different abstraction patterns that it's easy to lose track of which one you're using (and passing the wrong arguments with no static typechecking is a runtime error) and (b) JavaScript itself has so much wat (https://www.destroyallsoftware.com/talks/wat) in its implicit value coercions that it's invaluable to have types narrowly-scoped in code so you have any hope of predicting what the output of operations will be.


I don’t think JS is much worse than other dynamically typed languages to be honest. In Ruby you’d get an exception instead, which is mildly better than `NaN` in your user-visible text, but not much.

The DOM though is definitely complex and built of accretion over time. The Web resists refactoring because we can’t break websites from the 90s.


> I don’t think JS is much worse than other dynamically typed languages to be honest.

I agree; it's a plague all dynamically-typed languages face. I've yet to meet one that doesn't hit me with some kind of powerful pain-in-the-ass corner cases as a trade-off for the power of its terseness.

I fell in and out of love with Python over the course of a decade or so. Initially very excited about doing so much with so little code; fell out of love when I used it in an industry setting and realized 100% unit test coverage was mandatory because the lack of variable declaration means every line of code is a potential runtime error in waiting due to a simple name typo.


Python is strongly typed so doesn't suffer from coercion errors like js. Pyflakes has been a thing for a decade or two. Type checking is now well supported.


Pyflakes is better than nothing, but it is the nature of Python itself, IIUC, that it can't guard against variable typos because the mutable nature of the various contexts is such that the code under evaluation can't know if a variable name is referencing something that wasn't monkey-patched into scope via code in another module.

There's just no way to know that `if foo:` doesn't reference a foo that's supposed to be on the global scope.

(Contrast JavaScript, where `use strict` was added to force explicit reference to non-local scope).


While theoretically possible, this doesn’t happen unless you’ve put effort into destabilizing the code on purpose. Folks monkeypatch to fix problems, not create them.

You can explicitly mark a nonlocal or global as well.

Now if your project needs to be impervious to malicious actors, additional safeguards will be needed. But I’ve never encountered this situation in a long career.


It's not about the why, it's about the fact that because it's possible, the language has to allow for it.

Unless I'm mistaken (and please correct me if I am), no Python linter can address the fact that

`y = myVoriable + 3`

... is valid Python code because there's no way to know a-priori that `myVoriable` isn't a valid global variable, even though human inspection makes it obvious that it's a typo on `myVariable`. For that reason, there's a practical limit on how much static error checking Python allows as per the design of the language.

Has this been changed in the past decade? If so, I should give this language another chance.


No, pyflakes will catch that and always would to my knowledge. It did have a bug or three where it would miss an occasional issue but they were bugs (not impossible to detect) and fixed years ago.

The error message is slightly obtuse, says something like "variable only used once." But is clear after inspection the first time.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: