Ask HN: Why the Linux Kernel doesn't have unit tests?

Re:Ask HN: Why the Linux Kernel doesn't have unit tests? by yamtaddle on Friday November 25, 2022 @10:36AM (#33743312)

Static typing is machine-readable and machine-validatable documentation largely of a sort you should be writing anyway. If adding static types is a substantial burden either you're stuck with a really bad language, or you weren't writing enough documentation in the first place. Further, if things like much-improved autocomplete, far better editor-provided errors while editing, and better refactoring aren't saving you time, overall, we must write code very differently. And during handoff of code, static types are really nice and save tons of time.

[ Parent | on HN ]

Re:Ask HN: Why the Linux Kernel doesn't have unit tests? by IgorPartola on Friday November 25, 2022 @11:59AM (#33744354)

I am not writing code to make it easier for the computer to do its job. I am writing code so that the computer can make my job easier. Wasting time telling a computer how to show me autocomplete suggestions is better spent on creating APIs that are easier to use and require less of it. Or creating smarter autocomplete algorithms.

[ Parent | on HN ]

Re:Ask HN: Why the Linux Kernel doesn't have unit tests? by adwn on Friday November 25, 2022 @01:51PM (#33745562)

> Or creating smarter autocomplete algorithms.

Ah, the Sufficiently Smart IDE, companion to the Sufficiently Smart Compiler. Sure, go ahead and wait for the magic autocomplete algorithm that can deduce precise function signatures in a large Python or JavaScript code base.

Meanwhile, some of us have work to do, and we'll use the best tools at our disposal for managing non-trivial code written by many people across teams. And those tools include modern static type systems.

[ Parent | on HN ]

Re:Ask HN: Why the Linux Kernel doesn't have unit tests? by wadd1e on Friday November 25, 2022 @02:02PM (#33745669)

I think what the person replying was saying was not about static typing being easier for the compiler to understand, but the fact types being documented in some way(whether it be embedded in syntax or via documentation) make code far more readable.

Python was my first programming language(cliche, I know) and I didn't understand the whole "static typing is good" thing until I learnt languages like C, C++, C#, and rust.

Python also introduced type hints and made them a valid part of syntax for good reason. You'd typically end up writing a docstring with the return type of a function and the types of the parameters anyway, which is what the person replying to you was presumably referring to.

It's not about passing in an int instead of an array, but rather but being able to figure out what a function wants without needing a stackoverflow thread or having to search through tons of documentation for something that would be otherwise trivial in statically typed languages where the function declaration tells you quite a bit about a function.

Hence it's safe to say that types documented in code in some way are very useful for humans, and if you have issues with statically typed programming languages, there's a chance you were not documenting your code enough already.

[ Parent | on HN ]