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

201–210 of 276 posts

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

#201

Post by Goladus »

dllthomas wrote: post #182
Goladus wrote: post #127

Earlier quoted context omitted.

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.

True, but free usually means freedom from both cost and restraint, so the point doesn't change much. I should have said "constraint" rather than "cost".

Though the original commenter did follow-up, clarifying that the common interpretation of "free" doesn't closely match the point he'd intended to make

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

#202

Post by papsosouid »

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…

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

He didn't. He said "coke tasted better than pepsi". I've explained this to you several times already. You are the only one saying anything about "all the time in every context". You. Not the author, not his paper. You.

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

#203

Post by papsosouid »

x1 wrote: post #175
papsosouid wrote: post #150

Earlier quoted context omitted.

>I never suggested that Yes, you did suggest that. I am not sure how this level of cognitive dissonance is possible. What possible purpose does your example serve then if it doesn't impart any sort of meaning at all? >I'm not even sure what we are arguing about Clearly. Please, take the time to think through the subject and present a clear point that you will not later pretend you didn't make.

> What possible purpose does your example serve then if it doesn't impart any sort of meaning at all? The example shows that static typing doesn't do anything more than what it says. It doesn't solve problems/fix bugs or provide some magical insight to the system as you seem to believe. I'm genuinely curious as to your position and why you are so... clearly opinionated. I'll take the "idiot banner" for today. Please…

Again, provide a clear point if you want me to argue against it. Don't just say "I am going to keep making weird nonsensical posts and then pretend I didn't say what I clearly said and then blame you for replying" and expect me to grace you with some magical "insight".

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

#204

Post by debacle »

dllthomas wrote: post #191
debacle wrote: post #137

Earlier quoted context omitted.

If you are a good programmer, you don't need typing, you don't need interfaces, you don't need many things that make bad programmers better programmers. You might still use them, and there's nothing entirely wrong with that, but you probably don't need them. This is why so many people have problems writing JavaScript.

Even if you're a good programmer, typing and interfaces make refactoring quicker and typos easier to find. This is why so many people have problems writing in JavaScript.

Typing makes refactoring quicker only if you're relying on it. If you're not, then it will actually make refactoring slower.

Interfaces will not make refactoring faster, just easier.

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

#206

Post by davesims »

papsosouid wrote: post #199
anamax wrote: post #195

Earlier quoted context omitted.

> You do not test the potential of something by using the worst possible example of it. So? Folks don't use the "potential", they use the real. They're asking questions like "should I use Java or Python". > do airbags help prevent deaths" would be a very poor test if it used anything other than the best possible airbag technology. That's not how things actually work. You decide between what's available. The performan…

>So? Folks don't use the "potential", they use the real. Haskell is real. >They're asking questions like "should I use Java or Python". That's wonderful, but it has nothing to do with the subject at hand, which was the question "can static typing reduce the number of bugs?". If you want an answer to a different question, don't complain about the answer given for this question, go find someone answering the question y…

>Why can't anyone follow a simple line of reasoning without resorting to fallacies?

Indeed. The conclusion C was out of scope with the premises A and B. C is wrong, but that doesn't mean A and B cannot infer useful, more modest conclusions.

What I don't understand about every one of your responses is that you seem to think false equivalence applies in only one direction.

You seem to think it's fine for OP to infer broad conceptual conclusions from a small subset of the domain, but counter-examples to the broad claims cannot be applied, according to you, because, rather bizarrely you continue to insist that the counter-examples are too specific and and don't apply because the scope is general? That doesn't even make sense.

It's quite simple. OP claims "unit testing is not enough," "you need Static Typing" and uses broad language like "static type systems." I continually insist that such conclusions are out of the scope of the data given: The fact that type-related bugs were found in a handful of relatively small Python programs translated to an idiosyncratic environment like Haskell cannot possibly infer something so broad as what the OP is claiming.

Using Java/C++/Clojure/C#/etc. vs JavaScript/Lisp/Smalltalk/Ruby to give a counter-example is clearly within the scope of the argument. If OP had claimed something like "Python shows risk of static type errors, exposed by Haskell port" and claimed something like "more care and unit-testing is needed to guard against certain types of type-related bugs" I wouldn't have a problem. But that's not what OP claimed.

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

#207

Post by x1 »

zopa wrote: post #196
x1 wrote: post #177

Earlier quoted context omitted.

> But if you write a secure version, you only have to write it once. > You only have to maintain it in one place. > You only need to test it in one place. Again, so this cannot be done in a dynamic language? If it can be done, why bring them up? > And if you forget to use your secure Query type, anywhere else in your code, the compiler will yell at you. It's a significant advantage. The only thing the compiler will y…

> "The only thing the compiler will yell at you is if you passed a type that is not of a Query type. The compiler will not yell at you for getting the current session directly or creating your own jdbc driver for that matter." In Haskell, I'd have a module, Database, that held all my db code. That module would export functions something like query :: Query -> DBResult update :: Query -> DBAction -> DBResult (read tho…

> In the rest of my program, those functions would be the only way to talk to the database. There's your guarantee. Honest question. Take these pseudo sql calls:

    //Bad Person
    username = "lastname'; drop table user--"
    
    //Good Programmer
    query = "select * from users where name like %[username]%";
    input = {"username":"frank"};
    result = execute(query,input);
    
    //Bad Programmer
    query = "select * from users where name like '%"+username+"%'";
    result = execute(query, {});
vs

    //Bad Person
    String username = "lastname'; drop table user--"

    //Good Programmer
    Query q = new Query("select * from users where name like %[username]%");
    Input input = new Input(username);
    q.addInput(input);
    Result r = q.execute();
    
    //Bad Programmer
    Query q = new Query("select * from users where name like '%"+username+"%'");
    Result r = q.execute();
Could you solve this better using a static system? Right now I see no difference between the good and bad

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

#208

Post by zemo »

Peaker wrote: post #135
zemo wrote: post #49

Earlier quoted context omitted.

>type systems that are both usefully strict but also flexible. that's basically the design criteria behind Go's type system.

I think Go's type system is decades behind the state of the art. I can't believe they repeated the mistake of Boolean Blindness [1]. Sum types and pattern-matching are crucial for useful strictness with flexibility. This results in funny things like encoding the optional error result in Go as a type product rather than a sum, allowing reading of a result even if it does not exist due to an error. [1]: http://existent…

...your problem with Go is that it has a boolean type?

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

#209

Post by CodeMage »

davesims wrote: post #143
papsosouid wrote: post #114

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…

> That is precisely what it says

This is a very strong claim and it's false. The article doesn't say that anywhere. You interpret it that way.

I would hazard a guess that presenting your own interpretation as fact is what brought on those downvotes you complain about below.

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

#210

Post by Deestan »

simias wrote: post #105
Deestan wrote: post #12

Earlier quoted context omitted.

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

Such binary arguments bother me - Things won't degenerate to complete and utter chaos unless you go and add strict rules for everything. Good developers tend to follow the style of code they're in, and over time converge on a consistent style within projects or at least modules.

If they don't respect existing style, you don't have a "lack of rules" problem. You have a lack of education problem. Do code reviews. Point out to Bob that he's making the code less by letting the style alternate.

But you're sort of touching on what I meant when you say you don't want "chaos". If you can point at a code file and say "this is chaotic and hard to read - we could improve that by converging on style X or Y.", then we could come to some agreement.

Personally, I'd rather deal with slight aberrations in style than having a flaming row and angering half my team.

Post reply on HN