Live data from Hacker News

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

evanfarrer.blogspot.ca

181–190 of 276 posts

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

#181

Earlier quoted context omitted.

Wow thanks, I didn't know pyflakes. I knew pylint, but will make it more of a point to run it. I only occasionally need to code in Python, but when I have to, it is legacy code that I modify.

glad to be helpful. Depending on your editor of choice, you can get integrated pyflakes/pyling/flake8, e.g. I use vim and the syntastic plugin which is great. This way, you get a bit of on the fly static checking without needing to remember command line tools/using vcs hooks, which is much more productive.

Will keep this in mind the next time around!

Thanks again.

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

#182
post #121

Earlier quoted context omitted.

I am not claiming static typing is free. But it is also untrue that you have to "add declarations and type casts". With type inference, you don't actually have to.

But you have to use a language with type inference. That's still a cost. Maybe not a big one, but that was my point (and I'm definitely nitpicking a bit, I realize that.)

A constraint is only possibly a cost - if it forces behavior you wouldn't have chosen otherwise.

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

#183

Earlier quoted context omitted.

Yes, it was you. Why do you think the comparison should be "really bad static type system" vs "really good dynamic type system"? In what way does that make the test more useful? Allow me to say this again, as I do not know how to be any clearer: You do not test the potential of something by using the worst possible example of it. The only point of your desire is to reinforce the strawman that java = static typing. A…

Since this hasn't been already mentioned, and I run the risk of really flaming things up. Java has a very high propensity of generating runtime type errors. This is easily done by skirting the type checker with casting, which is commonplace. The upshot of me saying this is that I'm actually on the fence of even considering Java to be a statically-typed language for this reason...which is part of why I disagree with t…

As soon as you start using reflection in Java, you're doing non-statically-typed programming. Since a lot of popular Java frameworks use reflection implicitly - such as Spring, Hibernate, etc - that includes a lot of Java code that's out there.

And also, even if you carefully put a layer of explicit typechecking between the reflection based code, and the statically typed stuff, you're still throwing out the Java generics typechecking since none of that exists at runtime, and so your ArrayList can mysteriously contain non-String types when you finally access it.

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

#184
Slightly different view here.

I think the nirvana of typing is hybrid static/dynamic and it hit us with visual basic 6. I don't think anyone really noticed it though.

It supports traditional type checking by the compiler, runtime type inference and dynamic typing without boxing. Each case can be chosen at will. It supports all theoretical programs, supports unit testing and runtime assertions.

The least buggy software I've seen over the years was written in vb6 (by professionals, not the crap that haunts the web).

Now I'm not saying we should all switch to vb6 but some of the ideas may be worth investigating.

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

#185

Earlier quoted context omitted.

>which makes an unwarranted equivalence of all languages that have 'static type checking': No it doesn't. Read what you quoted, it says nothing even remotely resembling "this benefit applies to all languages with static typing". It is testing static typing, not a specific language. It uses the best static typing system to do so. You are entirely inventing the notion that this must then apply to java. > If the study w…

>it says nothing even remotely resembling "this benefit applies to all languages with static typing". That is precisely what it says, and that is reiterated later: "...the conclusion can be reached that...in practice [unit testing] is an inadequate replacement for static type checking." I'm not sure what you're reading, but there's no qualifications in the language used here regarding the idea of 'static type checkin…

From the downvotes I can only conclude that many of you wish the study didn't claim what it claims and are merely shooting the messenger. If anyone can point out rhetoric within the study that qualifies it in such a way as to make comparisons of other statically typed languages with other dynamically typed languages out-of-bounds or expressing a false equivalence within the scope of the conclusions of the study itself, I'll retract.

But so far all of the arguments I'm seeing against using, for instance, Java, are coming from a perspective not advocated by the study. You all have a point -- it's just not the point made by the paper.

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

#186
post #55

Earlier quoted context omitted.

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.

… And lo, PHP-2 was born into the world.

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

#187
post #118

Earlier quoted context omitted.

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

Zeno stirred a little...

Really stirred? I thought he proved that motion is impossible...

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

#188

Earlier quoted context omitted.

> Yeah, no shit. Stop drinking warm coke. Fine, then don't claim something like "All cokes in all contexts at all temperatures are better than all pepsis in all contexts at all temperatures." This is equivalent to what the study does with static vs. dynamic. Your argument, if you actually had a point, would be something along the lines of, "wait I'm talking about this boutique hand-crafted cola (Haskell) I get at Who…

I'm gonna have to disagree with you about the conclusion you're drawing. Yes, they are using the generic phrasing of "static typing" vs "dynamic typing", but this is because the study was intended to test the concept of static vs dynamic typing, not particular instances of it. However, seeing as we only have specific instances from which to test, it used the best one currently in widespread use. I don't see this as a…

> but this is because the study was intended to test the concept of static vs dynamic typing, not particular instances of it

Help me out here -- since the study confines itself to a handful of small Python programs translated to an idiosyncratic language like Haskell, how can the scope of the study possibly in any way qualify as a study on something so broad as "the concept of static vs. dynamic typing"?

Are you not confusing a better, more appropriate argument you'd make for the argument actually made in the paper?

EDIT: > Sure, it left that open as a possible interpretation for people looking for justification of a preconceived notion, but you can't really blame that on the authors.

Is that really an argument you want to make, that I can't blame an author for using broad and imprecise language that infers unwarranted conclusions in an academic paper?

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

#189

Earlier quoted context omitted.

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.

Dynamicity or dynamicness .

What's wrong with "dynamism"?
Post reply on HN