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

#61

Post by papsosouid » Wed, Jun 20, 2012, 2:56 PM UTC

kingkilr wrote: post #33

scott_s wrote: 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.

If most code doesn't use "dynamacism" (we'll pretend it is a word), then it isn't an important value for most people. You are suggesting people should use dynamic languages to gain no benefit because some other software might in theory benefit from it.

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

#62

Post by swannodette » Wed, Jun 20, 2012, 2:57 PM UTC

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 you want to support? The following support different styles of programming thus have very different static type systems.

  * Standard ML / OCaml
  * Haskell
  * Scala
  * Typed Racket
  * Qi

And there's still the question that some kinds of extremely useful programs are very difficult to write in popular languages with strong static typing. miniKanren, a flexible embedding of Prolog and Constraint Logic Programming into Lisp, comes to mind here. I've seen versions of miniKanren written in Haskell and it abandons the most powerful feature of miniKanren - it can be trivially applied back on the language it is written in!

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

#63

Post by soc88 » Wed, Jun 20, 2012, 2:58 PM UTC

cageface wrote: post #60

michaels0620 wrote: post #44

Earlier quoted context omitted.

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

Personally I like Scala but I think it's too complex and a little too clever to escape the FP niche. I'd be happy to be wrong about this.

Interesting. I never perceived Scala to be in a functional niche. As far as I know most people consider it to be an object-oriented language first and foremost, with functional features.

Removing inheritance would have made the language (and every other language, too) a lot easier, but seeing that people cope with C# or Java quite well I'm not sure about the merit of the "complex" claim.

Comparing the C# and the Scala spec is very enlightening, even though they have different writing styles of course (so I won't bother bringing up page numbers).

Checking and realizing which "features" are in one language, but not in the other, is very helpful to gain some insight into this topic.

What do you think?

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

#64

Post by x1 » Wed, Jun 20, 2012, 2:58 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…

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 wont tell you if that int is positive or negative or if that string is an email.

When dealing with either static/dynamic languages I think more unit tests should be spent validating.

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

#65

Post by kingkilr » Wed, Jun 20, 2012, 2:59 PM UTC

dons wrote: post #55

kingkilr wrote: post #41

Earlier quoted context omitted.

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…

Numerical algorithms suffer from a paucity of types. So either you enrich your numerical type hierarchy, or you prove an implementation matches a model, e.g. for fibonacci http://stackoverflow.com/a/8434107/83805

I don't have a response to that, other than to say, now you know why I decided to write compilers instead of pursue a graduate degree in computer science.

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

#66

Post by wtetzner » Wed, Jun 20, 2012, 2:59 PM UTC

Flow wrote: post #50

timclark wrote: post #3

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

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 :)

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

#67

Post by Dn_Ab » Wed, Jun 20, 2012, 2:59 PM UTC

emillon wrote: post #24

pja wrote: post #20

Earlier quoted context omitted.

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.

> Hindley-Milner type systems to the rescue! You're implying that all type-systems derived from HM have a form of bounded polymorphism. They're not, for example OCaml does not have type classes (you could probably encode a lot into objects, though).

OCaml's nephew, F# does have bounded polymorphism though. Although it inherits that from the OOP side of its family.

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

#68

Post by davesims » Wed, Jun 20, 2012, 3:00 PM UTC

pragmatic wrote: post #40

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

I can't speak for/to java but C# has come along way. I used to feel just like you did (at the asp.net 1.x) days. I went to Ruby on Rails for awhile. But once NET 2.0 (generics/nullable types) and then 3.5 (LINQ), I was hooked on C# again. We also have the dynamic type now. I want the features a statically typed language gives me with minimal boilerplate. It's hard to give up IDE features like "find everyplace this me…

I like C# these days quite a bit, after ~10 years in both Java and C#, and now ~7 in Ruby, my language preference is Ruby first, then C#. I do a lot of Android development these days too, so I retain a strong connection to Java.

But when I have to move from Rails to, say, ASP MVC (which is quite good, btw), generics are actually one of my biggest frustrations. Even with some of the quasi-dynamic typing available in C#, and even though I believe I have a pretty strong grasp of advanced generics concepts (in? out? Generic methods? Wildcards? Argh!) to me they introduce a maddening level of conceptual complexity and un-readability that are simply not worth the trouble.

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

#69

Post by AngryParsley » Wed, Jun 20, 2012, 3:01 PM UTC

Goladus wrote: post #51

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…

> 1. A common argument is that static-typed languages slow development. I'm not touching that land-mine. If you claim type-checking is free , the counter-argument is not that it "slows development." The counter is that type-checking is not free because it incurs measurable costs. You may sacrifice dynamic features, you may have to add declarations and type casts-- these are all costs whether they "slow development" o…

I would feel bad editing my comment now that you've replied, but my original intent was to say that type-checking is "free." At some point the quotes were lost.

To get as close to the land-mine as I am willing: I like C. I like Python. I like Ruby. But most of all, I like using the right tool for the job.

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

#70

Post by papsosouid » Wed, Jun 20, 2012, 3:01 PM UTC

x1 wrote: post #64

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…

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 you always use that function, and can't forget and accidently submit an unescaped string to the database.