Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

evanfarrer.blogspot.ca

Post reply on HN
Print view View original

161–170 of 276 posts

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

#161

Post by IsTom »

dochtman wrote: post #109
cageface wrote: post #10

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

What you are looking at are not two variables (strict, flexible), but also "ease of use". Arguably dependent-typed languages are most strict, but also most flexible: you can write type of a function that only accepts primes on input. They are hard to use though. Dynamically-typed languages are flexible and easy to use, but not strict. Java-likes are strict and easy to use, but they're very unflexible.

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

#162

Post by davesims »

papsosouid wrote: post #148
davesims wrote: post #143

Earlier quoted context omitted.

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

>I'm not sure what you're reading, but there's no qualifications in the language used here That is precisely my point. You are saying "this comparison of coke vs pepsi is no good because they used cold coke, and when I drink warm coke it isn't very good". Yeah, no shit. Stop drinking warm coke. Your decision to drink warm soda has no bearing on the test of cold soda vs cold soda.

> 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 Whole Foods, not that old Coke (Java), that's 20 years out of date!"

You're trying to retro-actively reduce the scope of a study you didn't write. The conclusions clearly use generic language that brings all static typed languages into a comparison with all dynamic languages. The false equivalence is not mine! It's the study's. If you want it differently, go write your own study that reduces the scope of the conclusions.

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

#163

Post by gnuvince »

ansible wrote: post #96
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.

> Something like Haskell with perhaps a little less religion about mutability is a whole different story. I consider Ocaml [1] to fill that particular niche. When I was going through my FP phase, I tried that out a little before going full-on lazy evaluation with Haskell. From what I can recall, the type inference isn't as cool as what's in Haskell, but at least it's there. There are plenty of libraries, and packages…

What do you mean by "the type inference isn't as cool as what's in Haskell"?

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

#164

Post by ocharles »

MatthewPhillips wrote: post #87
ocharles wrote: post #39

Earlier quoted context omitted.

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

Are you having fun because you switched to a statically typed language or are you having fun because you switched to a functional language? Would you be having less fun had you chosen Clojure?

You know, I'm probably having fun because of both. I love the type system Haskell gives me for exploring a problem space without diving into a solution. I am enjoying working in a functional language because it forces me to work in really small pieces and slot them together. I try and do this in Perl too, of course, but it can sometimes be easier to just cargo cult some things and forget to come back to them.

I think what I enjoy most is the type system though, and the ability to make massive refactorings until stuff compiles. 9 times out of 10, things just work after that.

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

#165

Post by hackinthebochs »

davesims wrote: post #162
papsosouid wrote: post #148

Earlier quoted context omitted.

>I'm not sure what you're reading, but there's no qualifications in the language used here That is precisely my point. You are saying "this comparison of coke vs pepsi is no good because they used cold coke, and when I drink warm coke it isn't very good". Yeah, no shit. Stop drinking warm coke. Your decision to drink warm soda has no bearing on the test of cold soda vs cold soda.

> 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 problem, nor do I think the wording of their conclusion necessarily implies anything about all instances of static typing currently in use. 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.

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

#166

Post by gnuvince »

thebluesky wrote: post #83
eta_carinae wrote: post #77

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

Tooling and performance are two largest advantages. Disadvantage is more verbosity, but it's a trade-off. With dynamically typed languages I find that you still need to worry about types, but you have to trace through the code to figure out what type a particular variable is (esp. if you're not the only one working on a project). In a statically typed language that information is readily available.

> Disadvantage is more verbosity, but it's a trade-off.

When I was learning Haskell, I wrote a program to count the value of a cribbage hand. The code was half the length of an equivalent JavaScript program.

The expressiveness of a language has more to do with the length of a resulting program than static or dynamic typing.

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

#167

Post by zopa »

njharman wrote: post #112

> "frequently cited claim by proponents of dynamically typed programming languages that static typing was not needed for detecting bugs in programs" Who says that? There's trade offs, multitudes, in choosing paradigm / language. It's never so black and white (except for academics, and twits who like to argue more than code) I did not read paper, don't have time for 60 pages of pointlessness.

> "Who says that?"

http://news.ycombinator.com/item?id=4137283 comes pretty close to making that claim, and that's just on this page.

> "There's trade offs, multitudes, in choosing paradigm / language. It's never so black and white"

Sometimes, it is. Most people don't use COBOL anymore, with reason; better languages came along. Programming is still a new field in the scheme of things. It would be strange if our languages were perfectly optimized, with no room for improvement without offsetting costs.

> "twits who like to argue more than code"

Some of us like to do both :) But go program; we won't stop you...

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

#168

Post by pyre »

Peaker wrote: post #139
pyre wrote: post #117

Earlier quoted context omitted.

> we've had runtime errors in Python code, due to [...] > type error, something a compiler would have caught Are wrongly spelled variable names and type errors the only runtime errors that you get? If not what percentage are they? Personally, I think that people tend to obsess about the specific type of errors because the 'solution' (static-typing) is something that already exists, whereas there is not easy solution…

In Python, there are a lot of errors like "NoneType has no attribute '...'", and those disappear too. Missing imports and redundant imports also go away. Lots of lots of invariants in the program can be encoded as types, too, so any bugs relating to them go away too. When you want parallelism, you get useful guarantees about not changing the deterministic result you had before you added parallelism. I used to use Pyt…

  > "NoneType has no attribute '...'"
C is statically typed, but I can still attempt to dereference a null pointer. Static typing doesn't save me here, nor does the compiler, as it's possible for these issues to happen at runtime.

This may be something that Haskell doesn't allow, but it's not something inherent to static-typing.

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

#169

Post by IsTom »

akkartik wrote: post #131
cageface wrote: post #10

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.

I haven't heard of anybody suggest that static languages should allow lists to contain arbitrary types. Hmm, do tuples cover all the use cases for that feature?

If you want a list of heterogenous "things" you either a list of "I don't care about what's on list" and then it should work without much in languages like Haskell, ML and the rest or you actually have list of things with a common property, such as "I want to be able to turn these things into strings and sum them" or "These are either numbers or strings" -- all functional languages work well with the latter through ADTs and the first one can be solved easily in Haskell with existential types (I don't know about other languages)

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

#170

Post by afrozenator »

pyre wrote: post #117
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…

> we've had runtime errors in Python code, due to [...] > type error, something a compiler would have caught Are wrongly spelled variable names and type errors the only runtime errors that you get? If not what percentage are they? Personally, I think that people tend to obsess about the specific type of errors because the 'solution' (static-typing) is something that already exists, whereas there is not easy solution…

Yes, probably that is my confirmation-bias at talk. But more than anything it is the frustration that the whole make into a par file and deploy it on a production system, only to find just moments later that the binary isn't up because of a typo is frustrating in any language.
Post reply on HN