Live data from Hacker News

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

evanfarrer.blogspot.ca

111–120 of 276 posts

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

#111
post #74

Earlier quoted context omitted.

No, this is just common ignorance of static typing. That string is a perfectly acceptable String. But it isn't a perfectly acceptable Query, and you can't pass a String to the database, only a Query. In order to turn a String into a Query, it has to be passed to a function that escapes problem characters safely. You need to use such a function regardless of dynamic vs static typing, but static typing enforces that yo…

> but static typing enforces that you always use that function, and can't forget and accidently submit an unescaped string to the database. So you're saying it is impossible to do this without static typing?

No, I am saying your strawman is a strawman. You were claiming static typing doesn't help since a string can contain a bad query. Now you are suggesting that you wouldn't write such code in a dynamically typed language anyways? Then why did you offer it as an example of how static typing doesn't help.

Of course you can make sure you never actually run the bad query with dynamic typing. I assumed it was obvious when talking about static typing that the difference would be compile time vs run time. 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.

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

#112
> "frequently cited claim by proponents of dynamically typed programming languages that static typing was not needed for detecting bugs in programs"

Who says that? There's trade offs, multitudes, in choosing paradigm / language. It's never so black and white (except for academics, and twits who like to argue more than code)

I did not read paper, don't have time for 60 pages of pointlessness.

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

#113
post #7
post #3

Interesting, but worth remembering, as Rich Hickey says, every bug has got past both your unit tests and your type checking.

That statement, though, is almost content-free. It's a truism. If you don't have type checking, then every bug has gotten past your unit tests; but some proportion may have been prevented with type checking. And vice versa. The statement doesn't say anything about the value or non-value of unit tests or type checking.

No, it's not content-free, at least when put back into context.

It's like coffee. If your coffee is shitty (complect), then no amount of sugar (unit tests) or cream (type checking) will make it any better.

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

#114

Earlier quoted context omitted.

>In addition, the hidden assumption is that all static and dynamic typing are created equal, i.e., since Haskell is statically typed and Haskell appears to have caught Python bugs that unit tests did not, therefore Java will catch bugs in a Ruby codebase, C++ will catch bugs in a JavaScript codebase, etc. That assumption isn't hidden, it is made up. By you. The question was "can static typing catch bugs that made it…

> That assumption isn't hidden, it is made up. By you. Not at all. The assumption is clearly implied by the conclusion of the study, which makes an unwarranted equivalence of all languages that have 'static type checking': "The translation of these four software projects from Python to Haskell proved to be an effective way of measuring the effects of applying static type checking to unit tested software." > Just beca…

>which makes an unwarranted equivalence of all languages that have 'static type checking':

No it doesn't. Read what you quoted, it says nothing even remotely resembling "this benefit applies to all languages with static typing". It is testing static typing, not a specific language. It uses the best static typing system to do so. You are entirely inventing the notion that this must then apply to java.

> If the study was meant to comprehend such a broad category as 'static type systems,' and from the explicit language of the study, it clearly was, then absolutely Java must necessarily be included

No it mustn't. Comparing the best of dynamic vs the best of static is a useful test. Just as nobody is complaining they didn't use a worse language than python, it makes no sense to complain they didn't use a worse language than haskell. You don't draw conclusions about the potential of X by examining the worst example of X possible.

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

#115
post #26

Earlier quoted context omitted.

I have not looked at the programs, but programs don't have to be long to be interesting. There are many "interesting" programs under 100 lines of code - and they can be important if they form the kernel of a larger program. Also, the author responds to a similar point in his comments: http://evanfarrer.blogspot.com/2012/06/unit-testing-isnt-eno...

The author doesn't really respond to the point, he simply says they were non-trivial in complexity, which may be true, but that doesn't mean they're non-trivial in their dynamacism (is that a word?). Moreover it in no way responds to the claim that these codebases aren't very good.

Dynamicity or dynamicness.

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

#116
post #110
post #81

Earlier quoted context omitted.

To have the compiler trap accidents for you? How would you do this if a query and a string were the same thing?

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…

Interestingly Wikipaedia lists SQL injection as being mitigated by strong typing (no I did not just edit it!) http://en.wikipedia.org/wiki/SQL_injection

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

#117

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…

  > we've had runtime errors in Python code, due to [...]
  > type error, something a compiler would have caught
Are wrongly spelled variable names and type errors the only runtime errors that you get? If not what percentage are they?

Personally, I think that people tend to obsess about the specific type of errors because the 'solution' (static-typing) is something that already exists, whereas there is not easy solution to other types of flaws.

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

#118

Earlier quoted context omitted.

> I'm going to argue that tests are actually free. > The alternative to automated testing is manual testing, not no testing. Actually, unit tests have different costs than manual testing. That doesn't make them free. For example, with unit tests, you now have more (possibly buggy) code to maintain.

> For example, with unit tests, you now have more (possibly buggy) code to maintain. Well, that's no problem. Just hit them with a bunch of unit tests...

Zeno stirred a little...

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

#119
post #74

Earlier quoted context omitted.

> but static typing enforces that you always use that function, and can't forget and accidently submit an unescaped string to the database. So you're saying it is impossible to do this without static typing?

No, I am saying your strawman is a strawman. You were claiming static typing doesn't help since a string can contain a bad query. Now you are suggesting that you wouldn't write such code in a dynamically typed language anyways? Then why did you offer it as an example of how static typing doesn't help. Of course you can make sure you never actually run the bad query with dynamic typing. I assumed it was obvious when t…

> 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 submit an unescaped string to the database.

So you are really just saying "static typing requires you to use static typing". This has nothing to do with actually writing good code or having any sort of validation. Just that the compiler tells you that you are sending the wrong type... that's what we are arguing about?

Look my whole point is static typing by itself gives you next to nothing (See my code example below) without some form of validation beyond static typing. That obviously holds true to dynamic typing as well... I'm not even sure what we are arguing about.

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

#120
There is a case for "optional typing". It's speed. I guess everyone agree on this one.

Better than "strict" typing, sometimes "hints" about the type would be enough.

ie: "ii often integer" versus "ii" or "ii integer"

From then on, those who favor strict typing would be happy, those who favor dynamic typing would be happy and those who favor "efficiency" (whatever this means) would be happy.

Let's close this silly debate.

Post reply on HN