The lack of static types really comes into play not inside a library, but in the interface between the external code and a library. Note that at least a few of the bugs that were found involved invalid API inputs. From the library writer's view it's not a bug because those values are not in the domain of defined behavior. From the caller's view it's a PITA that the library doesn't yell at them when they pass it garbage. Of course, they could find the problem with unit tests but the further up the food chain you get the more scarce unit tests tend to be.
Experiment: Unit testing isn't enough; You need static types, too
31–40 of 276 posts
Re: Experiment: Unit testing isn't enough; You need static types, too
#32Earlier 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).
False, ocaml has type classes now! (or maybe I'm thinking of coq)
Re: Experiment: Unit testing isn't enough; You need static types, too
#33If you can convert a program from one language to another (which is non-trivially different), in the time it takes to complete your masters, I'm pretty sure it wasn't a very interesting program. Further, the quality of the developers is going to play a large role in how effective any tool (and make no mistake, static typing is a tool) is. This is not intended as a disparaging remark to the authors, but in the 30 seco…
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.
Re: Experiment: Unit testing isn't enough; You need static types, too
#34The author's interpretation of the argument in favor of dynamic languages seems purposefully naive. I don't think that any proponent of dynamic languages or unit testing claimed that the mere presence of unit tests guaranteed bug free code or that it was impossible to have type related errors at run time if you have unit tests. It's a more nuanced argument asserting that the benefit to programmer productivity when using dynamic languages outweighs the cost of potential type related errors not possible in a statically typed language. Whether it has merit or not is the question I hoped this paper would answer.
Re: Experiment: Unit testing isn't enough; You need static types, too
#35I wonder how long it takes until the first one picks Java to argue against typed languages.
Re: Experiment: Unit testing isn't enough; You need static types, too
#36The 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.
pyflakes also detects typos easily, and it's quite useful.
In languages that don't catch anything you can usually still use tools for static verification.
As another example, Java may let you get NullPointerException, but FindBugs detects a lot of those.
Re: Experiment: Unit testing isn't enough; You need static types, too
#37I 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.…
Using Java and C# as an example of typed languages is like using Youtube comments as a representation of humanity.
Once you get a hang of them, writing in any modern statically typed declarative language enters you into a state such that code flows out effortlessly. It is a wonderful feeling.
Re: Experiment: Unit testing isn't enough; You need static types, too
#38How 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.
But could that kind of type system be considered similar to the usual Java-like little-flexible static typing? I think I would prefer a static vs dynamic implemented as Java vs Python (since those are usually the subjects on every one of these discussions)
Re: Experiment: Unit testing isn't enough; You need static types, too
#39I'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.
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 dynamic language now.
Re: Experiment: Unit testing isn't enough; You need static types, too
#40I 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 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 method is called" and know that you found all of them (disregarding reflection, etc and assuming private methods).
Visual Studio will do this type of thing for Python now. We aren't terribly far away from having the benefits of both.
I really like python as a scripting language. I just don't feel as good about scripting languages in big projects as I do a modern language like C#. (Just my humble opinion, no science).