Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

evanfarrer.blogspot.ca

Post reply on HN
Print view View original

11–20 of 276 posts

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

#11

Post by cageface »

glenjamin wrote: post #8

I applaud the effort to try and dissect the problem scientifically. If a whole program has 1 bug due to being implemented with dynamic types over static types, and that bug has gone unnoticed, then it can't be particularly important. The other common proposition is that dynamically typed languages are faster to write in than statically typed languages. If this is true then we need to compare the saving in development…

What? He specifically says that many of the bugs he discovered were exploitable. Just because you missed them doesn't mean some hacker won't.

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

#12

Post by Deestan »

crazygringo wrote: post #5
drharris wrote: post #4

It is definitely refreshing to see some actual evidence in something where arguments tend to be based on speculation, experience, or opinion. Now, we just need someone to research Emacs v. Vim, Tabs v. Spaces, etc.

Don't forget about braces versus indents, and above all, semicolons or not! :) On second thought, let's forget about them after all...

Any development environment where there exists a rule on Braces versus Indents is a place I'd stay well away from.

Put braces where they make the code readable. Use indents instead where they make the code more readable.

And if you do need a rule, make sure it's based on actual need. I.e. start the discussion with "the past two months we've had 4 non-trivial bugs which could have been avoided if we enforced braces.", not have a bunch of people bicker about their Personal Preferences (usually goes by the name "Best Practices").

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

#13

Post by SoftwareMaven »

crazygringo wrote: post #5
drharris wrote: post #4

It is definitely refreshing to see some actual evidence in something where arguments tend to be based on speculation, experience, or opinion. Now, we just need someone to research Emacs v. Vim, Tabs v. Spaces, etc.

Don't forget about braces versus indents, and above all, semicolons or not! :) On second thought, let's forget about them after all...

Braces really are evil, just because of how much time is spent bikeshedding about them. In what universe will a program function better if braces are on the end of the line or the next?

That's one thing I really like about go. It's nearly as opinionated about its braces as Python is about its not-braces (almost...).

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

#14

Post by sbmassey »

pimentel wrote: post #9

How can you translate from python to a static language, when the code is written for the interfaces, and not types? How willl you translate a function receiving a (possibly custom) iterable, when the function doesn't care about the type, but just whether it implements a next() method?

Haskell type classes are sufficiently flexible to represent things like 'does this type have a next method' without having to instrument the actual type.

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

#15

Post by Deestan »

glenjamin wrote: post #8

I applaud the effort to try and dissect the problem scientifically. If a whole program has 1 bug due to being implemented with dynamic types over static types, and that bug has gone unnoticed, then it can't be particularly important. The other common proposition is that dynamically typed languages are faster to write in than statically typed languages. If this is true then we need to compare the saving in development…

> The other common proposition is that dynamically typed languages are faster to write in than statically typed languages.

This part is also very tricky, as most of people's hard-earned experience with this is (almost by definition) old. In recent years, type inference has reduced the type-caused slowdown immensely. E.g. in Haskell you can (+) write large statically typed programs without specifying any types at all - they are inferred by the compiler.

(+) But please don't.

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

#16

Post by afrozenator »

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 passed the typechecker, it is logically correct. Though debugging in Haskell is truly a different ballgame altogether (I'm a Haskell noob).

I'll stop here lest this turns into a flame war.

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

#17

Post by gnuvince »

cageface wrote: post #10

I'm convinced that dynamically typed languages are a transitional technology that will be superseded once we develop type systems that are both usefully strict but also flexible. After over ten years working in dynamic languages I'm very happy to have a compiler on my side again.

What dynamic language were you using and which language are you using now?

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

#18

Post by dons »

pimentel wrote: post #9

How can you translate from python to a static language, when the code is written for the interfaces, and not types? How willl you translate a function receiving a (possibly custom) iterable, when the function doesn't care about the type, but just whether it implements a next() method?

> the function doesn't care about the type, but just whether it implements a next() method?

You're describing an "existential" type.

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

#19

Post by 16s »

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…

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.

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

#20

Post by pja »

pimentel wrote: post #9

How can you translate from python to a static language, when the code is written for the interfaces, and not types? How willl you translate a function receiving a (possibly custom) iterable, when the function doesn't care about the type, but just whether it implements a next() method?

Hindley-Milner type systems to the rescue! (With a sprinkling of Haskell style type classes.)

  f :: Iterable a => a -> b
  f x = (do stuff with x...)
f is defined to be constrained to accept only on types which implement the Iterable interface (however that's defined) as it's first argument and the compiler (or interpreter) will enforce that constraint.
Post reply on HN