It's hard to use lua for any sizeable chunk of code due to weak typing, absence of type hints and error handling. No it's not underrated in any way.
It's funny how through the years I've started to appreciate statically typed languages and type hints (Python, TypeScript) as well. Up to my current stance: it's a disservice for a community to write hintless python or js code.
P.S. Recently I've rewritten 1.5k cloc of JS into TypeScript. As usual there were dozens of cases of missed nulls, null attribute accesses or semantically questionable nulls.
It is because type inference has become a standard feature in most languages so you don't have to type AbstractBeanCounterSingletonFactoryFactory all the time.
Also the duck typing crowd were rebelling against polymorphism and over-used meta-programming OOP slop, not against types per se.
> Up to my current stance: it's a disservice for a community to write hintless python or js code.
Strongly disagree. If you are you using Python or Javascript or any other duck typing language you are supposed to know what you are doing and types are completely unnecessary. I'm amused at how the community in general praises and adopts TypeScript in so many projects. You can just write realiable JS code as it is. I have ever written any hinted Python code and everything just works as expected. If you need some guarantees then I would probably switch to some unit testing which at least for me brings more value that using types.
- Documentation is great, but documentation can fall out of date. Strong types usually can't; they are checked in both directions.
- Tests are great, but it's hard to maintain 100% coverage that checks all of what types do. It's very possible to have tests that pass that shouldn't. Types can not only find stealthily broken code, but also broken tests.
- Type checking gives even more instantaneous feedback than almost any test runner.
- Most projects have multiple developers. Types don't communicate everything, but they are a reliable form of communication that is guaranteed to be up-to-date even when documentation isn't, which is great combined with good function names and good parameter names.
- Most programs need to deal with requirements that shift, either because they evolve or our understanding evolves. Refactoring code without types is hard: if you change the return value of something, how can you be sure that all of the usages are up-to-date? What about if your refactor has been rebased a number of times before merging? I've run into a real-world production incident caused by this, when a return type changed to a tuple and it only exploded in an important Celery job that didn't have a test around the specific boundary that broke.
"If you know what you're doing" is not enough. Programs change, and they are changed by multiple people concurrently. This is the same reason why Rust continues to grow, people can say what they want but moving errors to the left is the only way forward because even if you're literally perfect you still have to know 100% of what's going on to never merge anything that causes a problem. (But really, people are not perfect, and never will be, so better tools Will win eventually.)
> - Most programs need to deal with requirements that shift, either because they evolve or our understanding evolves. Refactoring code without types is hard
I get perverse thrills out of drawing the attention of the "pfft, types are for n00bs" crowd to the multiple authentication related CVEs in GitLab due to the "well, the parameter types are whatever they are, don't you worry about it"
That said, I'm trying very hard to ween myself off even reading these threads, let alone contributing to them, because much like <https://news.ycombinator.com/item?id=42492508> I'm never going convince them and they for damn sure are never going to convince me
You can, but I can’t. I often just miss fixing some ident at a little clean up phase after prototyping yet another chunk.
unit testing which at least for me brings more value that using types
Not everyone writes for testing. E.g. I have large-enough ai related scripts in typescript that require types to feel safe to change. But I won’t create tests for these only to find typos and editing leftovers. Would be such a waste of time.
Typescript types are only required in “entry points” and live their own life afterwards thanks to inference. To me it was so worth it that I stopped creating js sandboxes for little experiments and made a ts project scaffolding script to spin up a new app in a few keystrokes.
And when you want to learn about “third party” code, types are irreplaceable. Code tells absolutely nothing compared to types. A single minute in .d.ts is worth an hour in .js.
Code always has types. Even in dynamic languages. The difference is whether those types can be expressed in the code, or have to be kept completely in your head (or constantly having to re-figure out what they are).
> you are supposed to know what you are doing and types are completely unnecessary
You are human, you simply can't.
I've literally found bugs in MY existing code by a mere rewriting it to TypeScript. It's the same story every single time. Even for projects with 100% test coverage.
It's funny how through the years I've started to appreciate statically typed languages and type hints (Python, TypeScript) as well. Up to my current stance: it's a disservice for a community to write hintless python or js code.
P.S. Recently I've rewritten 1.5k cloc of JS into TypeScript. As usual there were dozens of cases of missed nulls, null attribute accesses or semantically questionable nulls.