Experiment: Unit testing isn't enough; You need static types, too • Hacker News Board

Re: Experiment: Unit testing isn't enough; You need static types, too

#171

Post by IsTom » Wed, Jun 20, 2012, 5:18 PM UTC

swannodette wrote: post #62

Static types or static analysis? * KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs http://llvm.org/pubs/2008-12-OSDI-KLEE.html * Erlang Dialyzer http://www.erlang.org/doc/man/dialyzer.html * Datalog based systems http://www.cse.msu.edu/~cse914/Overheads/mmcgill-java-static-race-detector.pdf If you want static analysis hard coded into your language - what feature set do yo…

Dialyzer is not very good. We've been using it, but it rarely catches anything non-trivial. On the other hand Haskell has a better support for unit tests than many of dynamic languages.

Re: Experiment: Unit testing isn't enough; You need static types, too

#172

Post by afrozenator » Wed, Jun 20, 2012, 5:20 PM UTC

pyre wrote: post #168

Peaker wrote: post #139

Earlier quoted context omitted.

In Python, there are a lot of errors like "NoneType has no attribute '...'", and those disappear too. Missing imports and redundant imports also go away. Lots of lots of invariants in the program can be encoded as types, too, so any bugs relating to them go away too. When you want parallelism, you get useful guarantees about not changing the deterministic result you had before you added parallelism. I used to use Pyt…

> "NoneType has no attribute '...'" C is statically typed, but I can still attempt to dereference a null pointer. Static typing doesn't save me here, nor does the compiler, as it's possible for these issues to happen at runtime. This may be something that Haskell doesn't allow, but it's not something inherent to static-typing.

In static-typing's defense, C isn't as strictly typed as Haskell, a pointer (and therefore null) is just basically an integer.

But I totally agree, static typing is no cure for a wrong program. With power/expressiveness also comes a great ability to goof up.

Re: Experiment: Unit testing isn't enough; You need static types, too

#173

Post by hackinthebochs » Wed, Jun 20, 2012, 5:25 PM UTC

debacle wrote: post #78

The better programmer you are, the less you need static types. But a group of ten programmers create a codebase that is only as good as the worst programmer's code.

Let me guess, you love dynamic languages, right?

I really wish we would all stop ourselves when we're about to make a statement of the form "Great programmers do X (which I happen to do)". Without any rationale to back it up, its just ego-stroking.

Re: Experiment: Unit testing isn't enough; You need static types, too

#174

Post by afrozenator » Wed, Jun 20, 2012, 5:26 PM UTC

riffraff wrote: post #36

16s wrote: post #19

Earlier quoted context omitted.

pylint can help with misspelled variables and type errors. I started using it recently and love it. I still love my C++ compiler though and would not trade it for anything else.

pyflakes also detects typos easily, and it's quite useful. In languages that don't catch anything you can usually still use tools for static verification. As another example, Java may let you get NullPointerException, but FindBugs detects a lot of those.

Wow thanks, I didn't know pyflakes. I knew pylint, but will make it more of a point to run it. I only occasionally need to code in Python, but when I have to, it is legacy code that I modify.

Re: Experiment: Unit testing isn't enough; You need static types, too

#175

Post by x1 » Wed, Jun 20, 2012, 5:26 PM UTC

papsosouid wrote: post #150

x1 wrote: post #119

Earlier quoted context omitted.

> Now you are suggesting that you wouldn't write such code in a dynamically typed language anyways? I never suggested that...? > With a statically typed language, when you make the error, you get told about it by the compiler. With a dynamically typed language, you find out about the error later, when that code actually runs. > static typing enforces that you always use that function, and can't forget and accidently…

>I never suggested that Yes, you did suggest that. I am not sure how this level of cognitive dissonance is possible. What possible purpose does your example serve then if it doesn't impart any sort of meaning at all? >I'm not even sure what we are arguing about Clearly. Please, take the time to think through the subject and present a clear point that you will not later pretend you didn't make.

> What possible purpose does your example serve then if it doesn't impart any sort of meaning at all?

The example shows that static typing doesn't do anything more than what it says. It doesn't solve problems/fix bugs or provide some magical insight to the system as you seem to believe.

I'm genuinely curious as to your position and why you are so... clearly opinionated. I'll take the "idiot banner" for today. Please provide me with your insight as to what the fundamental argument (and why you feel so strongly about it) really is.

Re: Experiment: Unit testing isn't enough; You need static types, too

#176

Post by Peaker » Wed, Jun 20, 2012, 5:26 PM UTC

pyre wrote: post #168

Peaker wrote: post #139

Earlier quoted context omitted.

In Python, there are a lot of errors like "NoneType has no attribute '...'", and those disappear too. Missing imports and redundant imports also go away. Lots of lots of invariants in the program can be encoded as types, too, so any bugs relating to them go away too. When you want parallelism, you get useful guarantees about not changing the deterministic result you had before you added parallelism. I used to use Pyt…

> "NoneType has no attribute '...'" C is statically typed, but I can still attempt to dereference a null pointer. Static typing doesn't save me here, nor does the compiler, as it's possible for these issues to happen at runtime. This may be something that Haskell doesn't allow, but it's not something inherent to static-typing.

Static typing can alleviate that, and that's how Haskell does.

The problem with C is that nullability is not statically typed.

Re: Experiment: Unit testing isn't enough; You need static types, too

#177

Post by x1 » Wed, Jun 20, 2012, 5:32 PM UTC

zopa wrote: post #144

x1 wrote: post #110

Earlier quoted context omitted.

So when the Query is sent to the database MySQL actually receives a Query object and then parses that Query object? ...oh wait, right before it is sent to mysql it is turned back into a string again. My point is that static typing doesn't help you do anything other than verify that the objects being passed are of a particular type. I'm not saying static typing is bad or good I'm just saying that type checking itself…

Yes, you can write a Query type that is vulnerable to SQL injection, if you want to. But if you write a secure version, you only have to write it once. You only have to maintain it in one place. You only need to test it in one place. And if you forget to use your secure Query type, anywhere else in your code, the compiler will yell at you. It's a significant advantage. This is easier to see in a language with a rich,…

> But if you write a secure version, you only have to write it once.

> You only have to maintain it in one place.

> You only need to test it in one place.

Again, so this cannot be done in a dynamic language? If it can be done, why bring them up?

> And if you forget to use your secure Query type, anywhere else in your code, the compiler will yell at you. It's a significant advantage.

The only thing the compiler will yell at you is if you passed a type that is not of a Query type. The compiler will not yell at you for getting the current session directly or creating your own jdbc driver for that matter.

Re: Experiment: Unit testing isn't enough; You need static types, too

#178

Post by riffraff » Wed, Jun 20, 2012, 5:37 PM UTC

afrozenator wrote: post #174

riffraff wrote: post #36

Earlier quoted context omitted.

pyflakes also detects typos easily, and it's quite useful. In languages that don't catch anything you can usually still use tools for static verification. As another example, Java may let you get NullPointerException, but FindBugs detects a lot of those.

Wow thanks, I didn't know pyflakes. I knew pylint, but will make it more of a point to run it. I only occasionally need to code in Python, but when I have to, it is legacy code that I modify.

glad to be helpful.

Depending on your editor of choice, you can get integrated pyflakes/pyling/flake8, e.g. I use vim and the syntastic plugin which is great.

This way, you get a bit of on the fly static checking without needing to remember command line tools/using vcs hooks, which is much more productive.

Re: Experiment: Unit testing isn't enough; You need static types, too

#179

Post by Symmetry » Wed, Jun 20, 2012, 5:41 PM UTC

kingkilr wrote: post #41

dons wrote: post #28

Earlier quoted context omitted.

If you're hoping to catch a specification error, don't use a type like `Integer -> Integer`, which doesn't capture the specification except in a most general sense. Just as you should write good tests, that actually test for useful properties, so you should write good types -- and get useful proofs back from the compiler as a result.

I wasn't trying to catch the error of "program author is a moron who doesn't know the difference between Fibonacci and factorial". Were I trying to catch that error I would have been aware of it, and then much less likely to write the bug in the first place. This is a truism that is well accepted by testing proponents: which tests you write are incredibly important, and you need to write your tests first in order to…

The point about a static type system not catching all errors is well taken[1], but if a programmer has mixed up factorial and Fibonacci I would expect that their tests would reflect this as well as their code. This is more the sort of thing you should rely on code reviews to spot.

[1] Isn't the old joke in Haskell "If your program compiles it probably does something someone would find useful, but not necessarily the useful thing you want"

Re: Experiment: Unit testing isn't enough; You need static types, too

#180

Post by afrozenator » Wed, Jun 20, 2012, 5:41 PM UTC

kingkilr wrote: post #25

afrozenator wrote: post #16

The author really needs to be complemented on rewriting swathes of code from Python to Haskell. In Google, in my project, we've had runtime errors in Python code, due to wrongly spelled variables(although that is a different problem), and type error, something a compiler would have caught. Strong type checking is something that I truly like about Haskell and OCaml, I'm reasonably convinced that once my program has pa…

I'm reasonably convinced that once my program has passed the typechecker, it is logically correct Yup, this is one of my favorite things about Haskell, that's how I know that http://bpaste.net/show/32033/ is a totally correct program.

I forget whose quote this is - The computer is a wonderful machine, it does what I tell it to do, not what I want it to do.

Your point taken, but that is a problem in programming language X, which has Y type system, for all permissible values of X and Y.