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

#71

Post by Flow » Wed, Jun 20, 2012, 3:03 PM UTC

wtetzner wrote: post #66

Flow wrote: post #50

Earlier quoted context omitted.

Speaking of Clojure, I've recently started to learn it since I like Richs reasoning about state, time, value and so on. His speeches are nothing short of fantastic in my opinion. Anyway, it occurred to me that with Clojure it could easily happen that I trade bugs caused by state problems to bugs cause by type problems.

> Anyway, it occurred to me that with Clojure it could easily happen that I trade bugs caused by state problems to bugs cause by type problems. With Haskell, on the other hand, you may not need to trade :)

Yes, I know. Haskell is a very cool language as well.

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

#72

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

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

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

#73

Post by dllthomas » Wed, Jun 20, 2012, 3:09 PM UTC

wtetzner wrote: post #58

kingkilr wrote: post #53

Earlier quoted context omitted.

a) If you aren't touching that land mine you're missing the point. You can't say that one is free (except maybe it has a cost), and the other has a cost. That's just nonsensical. b) Second, I'm going to argue that tests are actually free. And I think this because I don't care how good static type proponents think they are, I know they don't wait until it compiles and SHIP SHIP SHIP, they actually run their damned pro…

> 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...

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

#74

Post by x1 » Wed, Jun 20, 2012, 3:10 PM UTC

papsosouid wrote: post #70

x1 wrote: post #64

Earlier quoted context omitted.

Are we really talking about type checking or the larger circle of validation (of which type checking is just a small part)? ( Bugs found by unit tests ( ) Bugs found by input validation ) Or in other words... String s = "lastname'; drop table user--"; ...is still a perfectly acceptable string. It seems to me that type checking is the simplest form of validation (are you an int, are you a String) and nothing more. It…

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?

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

#75

Post by gtani » Wed, Jun 20, 2012, 3:11 PM UTC

http://tratt.net/laurie/tech_articles/articles/a_modest_atte...

http://www.tbray.org/ongoing/When/201x/2011/12/27/Type-Syste...

http://blog.jcoglan.com/2011/12/29/black-box-criteria/

http://www.stanford.edu/class/cs242/slides/Types.ppt

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

#76

Post by thebluesky » Wed, Jun 20, 2012, 3:11 PM UTC

michaels0620 wrote: post #44

cageface wrote: post #30

Earlier quoted context omitted.

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.

Does Scala fit your idea of something in between? It has nice type inference features and does not require pure immutability.

I've found Scala to combine the best of both worlds, non-verbose and statically typed.

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

#77

Post by eta_carinae » Wed, Jun 20, 2012, 3:11 PM UTC

The advantage of statically typed languages has a lot less to do with tests and everything to do with tools. IDE's can do very little when no type information is available, and most automatic refactorings require human supervision when performed on dynamically typed languages (read this for details: http://beust.com/weblog/2006/10/01/dynamic-language-refactor... ).

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

#78

Post by debacle » Wed, Jun 20, 2012, 3:12 PM UTC

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.

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

#79

Post by eta_carinae » Wed, Jun 20, 2012, 3:14 PM UTC

cageface wrote: post #27

gnuvince wrote: post #17

Earlier quoted context omitted.

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

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.

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

#80

Post by bad_user » Wed, Jun 20, 2012, 3:17 PM UTC

johnkchow wrote: post #23

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…

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.…

     I hated IoC containers as well as writing all
     that boilerplate code for Attributes

C# and Java are only representative for static languages because they are mainstream.

My static language of choice is currently Scala. It is less verbose than both C# and Java (for example you never have to generate setters/getters). Also, whenever I work with Java I always work with projects such as Lombok / Guava.

And I have no need for "IoC containers". This is partly because of Scala, but also because of the libraries I'm using. Currently I'm using DropWizard for the development of web services, which is just a thin wrapper around Jetty + JAX-RS. Because the resources (commonly known as controllers in MVC frameworks) are configured as instances (not classes specified in web.xml), then IoC is easy because you are free to do the bindings yourself.

IMHO, the necessity for IoC containers in C# / Java has risen from poorly designed frameworks. So you may not have a choice in the matter, however using something like Google Guice in combination with Scala is much nicer, because of Scala's mixins in combination with structural typing.