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

#91

Post by cageface » Wed, Jun 20, 2012, 3:26 PM UTC

MatthewPhillips wrote: post #87

ocharles wrote: post #39

Earlier quoted context omitted.

Amen, I've spent the last 3 years of my career working on an increasingly complicated Perl project and frankly, I've had enough. My pet projects now are all Haskell and I can't believe how fun it is. I spend most of my time these days fixing bugs and regressions due to the sheer scale of the project, and I'm a running meme at work for saying "a type checker could have caught that!". I can't imagine going back to a dy…

Are you having fun because you switched to a statically typed language or are you having fun because you switched to a functional language? Would you be having less fun had you chosen Clojure?

I started a parallel implementation of a bunch of machine learning algorithms in Clojure and Scala. I figured the Clojure version would pull out ahead thanks to my previous lisp experience and lisp's history in that domain.

I was very surprised to discover that my Scala code was a lot easier to understand and maintain and had fewer bugs.

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

#92

Post by zmoazeni » Wed, Jun 20, 2012, 3:31 PM UTC

AngryParsley wrote: post #43

I think most people would agree that these two circles overlap on a Venn diagram: ( Bugs found by unit tests ( ) Bugs found by type-checking ) The disagreement is how much. Also, type-checking is free[1], while unit tests have to be manually written. I'm glad someone spent a lot of time trying to answer this question, but I don't think it will affect my choice of language in any new project. I like to write code in t…

Context: My day job has been coding Ruby for years, and I'm a big fan of Haskell.

Someone was asking me about my thoughts on static vs dynamic. And I realized that I have two reasons for my tests a) I didn't do something stupid like mistype a method or variable name and b) validate my logic.

Sometimes I think it swings 20/80 and others 80/20. But either way, I know that's why I gravitate towards integration tests in Ruby, and that some of them would go away if it were statically typed.

Even after coding in Ruby all these years, I'm still just as afraid of (and susceptible to) problems in a).

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

#93

Post by hotlikearobot » Wed, Jun 20, 2012, 3:32 PM UTC

gaius wrote: post #81

x1 wrote: 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?

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

He is making the point that you can create a separation between Query and string just as easily in a dynamic language; it just gets caught at runtime (preferably during testing) rather than compile time.

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

#94

Post by chc » Wed, Jun 20, 2012, 3:32 PM UTC

kingkilr wrote: post #84

drunkpotato wrote: post #72

Earlier quoted context omitted.

He qualified with "reasonably convinced", and you countered with an unreasonable example. That is the definition of attacking a strawman.

It's not unreasonable, it only seems unreasonable because of the context. I've seen several really good programmers (and overall bright people) mix the implementation of the two up.

If you have the two algorithms mixed up, unit tests aren't going to save you either. Nothing will ever save you from intending to do the wrong thing.

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

#95

Post by awj » Wed, Jun 20, 2012, 3:33 PM UTC

x1 wrote: post #74

papsosouid wrote: post #70

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?

I don't think anyone is making that claim. You can obviously do runtime inspections of types before building the query, or rely on the "runtime inspection" of getting an exception when the unescaped String doesn't support the Query method being used.

It's entirely possible to do this without static typing. It's impossible to guarantee that all database calls use a Query instead of a String without running the code in some form.

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

#96

Post by ansible » Wed, Jun 20, 2012, 3:34 PM UTC

cageface wrote: post #30

johnkchow wrote: post #23

Earlier quoted context omitted.

From my personal experience, the saving in development time is very much real. I used to work on .NET, and you'd have to program against crazy, non-intuitive patterns in order to have your code "clean" (I hated IoC containers as well as writing all that boilerplate code for Attributes. And for Java, remember that hilarious post about Factory-Factory-Factory patterns http://discuss.joelonsoftware.com/default.asp?joel.…

The kinds of static type systems you find in C# & Java are too primitive. Something like Haskell with perhaps a little less religion about mutability is a whole different story.

> Something like Haskell with perhaps a little less religion about mutability is a whole different story.

I consider Ocaml [1] to fill that particular niche. When I was going through my FP phase, I tried that out a little before going full-on lazy evaluation with Haskell.

From what I can recall, the type inference isn't as cool as what's in Haskell, but at least it's there. There are plenty of libraries, and packages for major OSs.

[1] http://caml.inria.fr/ocaml/

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

#97

Post by gaius » Wed, Jun 20, 2012, 3:34 PM UTC

eta_carinae wrote: post #79

cageface wrote: post #27

Earlier quoted context omitted.

I pretty much lived in Rails from 2004-2011 but did a lot of Python and Perl before that. These days it's mostly C++/Obj-C but I'm keeping an eye on Haskell for iOS.

> I'm keeping an eye on Haskell for iOS. Really? Is that even possible? Can't imagine Apple being okay with that.

Sure, GHC is on ARM now.

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

#98

Post by jerf » Wed, Jun 20, 2012, 3:40 PM UTC

cyrus_ wrote: post #56

AngryParsley wrote: post #43

I think most people would agree that these two circles overlap on a Venn diagram: ( Bugs found by unit tests ( ) Bugs found by type-checking ) The disagreement is how much. Also, type-checking is free[1], while unit tests have to be manually written. I'm glad someone spent a lot of time trying to answer this question, but I don't think it will affect my choice of language in any new project. I like to write code in t…

Many of the unit tests would have to be written in a simply-typed language like Haskell too -- the author notes that only a handful of tests could be entirely eliminated due by the rewrite. Probably worth further study.

In my admittedly-limited personal experience doing something similar, it's really hard to characterize this in a sane way. What you end up with is a pile of unit tests which are "really testing something", yet, some non-trivial percentage of the tests are still redundant to the type system. You feel like you can't throw it away because of the percentage that is a real test of functionality, but if you'd been starting from scratch with the stronger type system you'd have written fewer tests with very different focus.

It's hard to even come up with an example, but consider testing that an HTML generation library doesn't unexpectedly emit text unescaped. The pile of tests you write if you're in Python or Perl mostly translate to Haskell unscathed, in that each individual test still is testing something ("is the href attribute on encoded properly? is the name attribute on encoded properly? ..."), yet considered as a whole the tests have significant redundancy with the type system, because if you set the types up correctly there's a great deal fewer possible ways to screw up than there used to be.

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

#99

Post by mikeryan » Wed, Jun 20, 2012, 3:40 PM UTC

AngryParsley wrote: post #43

I think most people would agree that these two circles overlap on a Venn diagram: ( Bugs found by unit tests ( ) Bugs found by type-checking ) The disagreement is how much. Also, type-checking is free[1], while unit tests have to be manually written. I'm glad someone spent a lot of time trying to answer this question, but I don't think it will affect my choice of language in any new project. I like to write code in t…

Also, type-checking is free[1], while unit tests have to be manually written.

The use of type-checking doesn't negate the need for unit tests. It just adds another layer of validation. The Unit Test "cost" is still there.

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

#100

Post by simias » Wed, Jun 20, 2012, 3:42 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.

No true scotsman much?