Live data from Hacker News

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

evanfarrer.blogspot.ca

101–110 of 276 posts

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

#101

The sample size of this study is statistically too insignificant to draw the conclusions given. The counterfactuals to the claims of dynamic type advocates were already true and provable, so even if the sample size of the codebases studied were statistically significant (not to mention vetted for quality of unit test as well as coverage ) the conclusions are nevertheless trivial. In addition, the hidden assumption is…

>In addition, the hidden assumption is that all static and dynamic typing are created equal, i.e., since Haskell is statically typed and Haskell appears to have caught Python bugs that unit tests did not, therefore Java will catch bugs in a Ruby codebase, C++ will catch bugs in a JavaScript codebase, etc.

That assumption isn't hidden, it is made up. By you. The question was "can static typing catch bugs that made it past a decent (and common) test suite". The answer to that can drive interest in static typing, and thus more language with useful static type systems. Just because java has a crappy type system, doesn't mean we should be content with that.

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

#102

The sample size of this study is statistically too insignificant to draw the conclusions given. The counterfactuals to the claims of dynamic type advocates were already true and provable, so even if the sample size of the codebases studied were statistically significant (not to mention vetted for quality of unit test as well as coverage ) the conclusions are nevertheless trivial. In addition, the hidden assumption is…

[deleted]

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

#103
post #81
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?

That is why you make them separate. You only really start taking advantage of the type system after you learn to encode system invariants and rules into the type system.

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

#104
post #100
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?

I don't know how you could contrive what I said to be cognitive dissonance.

If you have a team of N good programmers, you can probably write without static typing. If you have a team of N-1 good programmers and 1 bad programmer, you should really use a language static typing.

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

#105
post #12

Earlier quoted context omitted.

Don't forget about braces versus indents, and above all, semicolons or not! :) On second thought, let's forget about them after all...

Any development environment where there exists a rule on Braces versus Indents is a place I'd stay well away from. Put braces where they make the code readable. Use indents instead where they make the code more readable. And if you do need a rule, make sure it's based on actual need. I.e. start the discussion with "the past two months we've had 4 non-trivial bugs which could have been avoided if we enforced braces.",…

I disagree. I prefer a development environment that settles on a coding style, even if I don't like it, rather than chaos. I find reading code using multiple coding style painful.

It also ends the bikeshedding, "that's how we do it there, deal with it".

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

#106

The sample size of this study is statistically too insignificant to draw the conclusions given. The counterfactuals to the claims of dynamic type advocates were already true and provable, so even if the sample size of the codebases studied were statistically significant (not to mention vetted for quality of unit test as well as coverage ) the conclusions are nevertheless trivial. In addition, the hidden assumption is…

>In addition, the hidden assumption is that all static and dynamic typing are created equal, i.e., since Haskell is statically typed and Haskell appears to have caught Python bugs that unit tests did not, therefore Java will catch bugs in a Ruby codebase, C++ will catch bugs in a JavaScript codebase, etc. That assumption isn't hidden, it is made up. By you. The question was "can static typing catch bugs that made it…

> That assumption isn't hidden, it is made up. By you.

Not at all. The assumption is clearly implied by the conclusion of the study, which makes an unwarranted equivalence of all languages that have 'static type checking':

"The translation of these four software projects from Python to Haskell proved to be an effective way of measuring the effects of applying static type checking to unit tested software."

> Just because java has a crappy type system, doesn't mean we should be content with that.

I don't know what this means. If the study was meant to comprehend such a broad category as 'static type systems,' and from the explicit language of the study, it clearly was, then absolutely Java must necessarily be included. Otherwise, the study, as I noted, should have restricted its conclusions to a scope of Haskell vs. Python, with at most modest and well-qualified statements regarding the broader implications of static vs. dynamic in general.

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

#107

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.

[deleted]

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

#108
post #63

Earlier quoted context omitted.

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

I don't think page counts of specs or feature lists really tell you that much. I didn't find it that hard too get up to speed in Scala but it seems to scare away too many Java people. My main criticism is that it allows too much syntactic flexibility.

Yes, I'm full aware of that. I'm not claiming that it tells us the complete and final truth, just that it is an interesting data point.

In my experience a lot of those "I programmed 15 years in Java, get off my lawn" senior developers get angry about Scala. This is interesting, because it isn't that way for other languages running on the JVM like Clojure, JRuby or Groovy.

It is only a speculation why it is like that, but in my opinion it is because alternatives like Groovy, JRuby, Clojure are considered to be some sort of "supplemental" or "add-on" languages by those people, while Scala is seen as full-scale alternative to Java (not in the sense that it will replace Java, but in the sense of "I can write 100% of my application in this language without dropping down to Java for the performance critical parts").

I think it is interesting how different the reaction is compared to C# F#, for instance. Is it because Java and C# developers come from different backgrounds? Because F# is "made by Microsoft", while Scala is not "made by Oracle"? Is it because Java developers were happy with Sun telling them that they wouldn't need all those "fancy" features of the .NET languages? I think this would be interesting to discuss further, although I think it is hard to come up with valid data points.

From my experience, most of the claims about "complexity" and "too hard for beginners" come not from people learning the language, but from people with > 5 years of Java experience _not_ wanting to learn another language.

I'm quite ambivalent about the syntactic flexibility. On the one hand, they cut it down for 2.10, but on the other I think it is a superficial measurement. There are a lot of languages with more flexibility and a lot of languages with less, both seem to be alive and well. (Just want to make it clear that I think your stance is totally valid, even if I disagree slightly. Different people have different tastes, and this is a good thing!)

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

#109

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

Seems to me that that's what static typing proponents have been saying for years (if not decades), and it still isn't true.

That said, I'm currently hacking on a compiler to see if I can come up with a design for a static language that's almost as pleasant to use as a dynamic one, so I'm not completely hopeless. But it certainly seems like the data point that until now no such superior type system (strict but flexible) has become widely popular should not be underestimated.

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

#110
post #81
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?

So when the Query is sent to the database MySQL actually receives a Query object and then parses that Query object?

...oh wait, right before it is sent to mysql it is turned back into a string again.

My point is that static typing doesn't help you do anything other than verify that the objects being passed are of a particular type. I'm not saying static typing is bad or good I'm just saying that type checking itself is NEARLY USELESS unless you include some sort of validation.

		Query q = new Query("select * from users where id = (id)");
		QueryParam qp = new QueryParam("(id)",25);
		q.addParam(qp);
		ResultSet rs = q.execute();
		public class Query {
			public ResultSet execute() {
			for(QueryParam qp : this.getQueryParams()) { 
				this.getSql().replace(qp.getId(),qp.getValue());
			}
			super.execute(sql);
			}
		}
That's all type safe. So it should be good right?
Post reply on HN