Live data from Hacker News

Study of 49 programmers: static type system had no effect on development time

cs.washington.edu

181–190 of 192 posts

Re: Study of 49 programmers: static type system had no effect on development time

#181

Earlier quoted context omitted.

Depends on the IDE. I use Python with Eclipse. Auto-completion works quite perfectly. Refactoring too.

I disagree. There's simply no way that the IDE can know everything about a variable without running the code and I don't believe that eclipse does this. It's ok at refactoring but it breaks down all the time for me, renaming unrelated variables or missing cases. I don't believe it can handle kwargs for example (no computer in front of me, feel free to prove me wrong)

> There's simply no way that the IDE can know everything about a variable without running the code

Or with. With dynamic typing and dynamic name resolution such as in Python, there's no way to know with certainty, even if you run it.

Re: Study of 49 programmers: static type system had no effect on development time

#182

Earlier quoted context omitted.

By limiting the damage a single crappy programmer can do. Everywhere people talk about 'large' teams maintaining a large codebase in this thread, substitute 'mediocre' teams stuck with a poor bloated codebase that is the vehicle for their ambitions. It's just not worth anybody's time to understand its unique needs in detail, especially since any improvement you make today risks being messed up tomorrow.

I can understand using static typing if you already have a large codebase that's statically typed, but is there any reason you'd start a project with a statically typed language?

Yeah the benefits of static typing are front-loaded at the start of a project. I might rewrite in a statically-typed language for performance if it ever needs it, but I wouldn't start statically-typed.

My lisp interpreter above allows me to tear out a lisp function and replace it with a C function, while leaving the unit tests untouched.

Re: Study of 49 programmers: static type system had no effect on development time

#183

The study may or may not be flawed, but what's really interesting to me is the reaction. We need more science in our computer science, which means more experiments and more results like this. We should also be open to the truth that we use the tools we like because we like them rather than because they're technically superior, even though we pimp them ad nauseum as though they are. I once read an article about a tech…

I don't know how science can help you here. In the case of the improved fan design, well that's easily testable. However, I don't want to go down the rabbit hole and argue social vs natural sciences. I find it dumbfounding that in this day and age, people can still create rather arbitrary social experiments with only 49 people and then think they can draw grandiose conclusions from their "data".

Unfortunately, user studies are difficult to conduct in computer science mainly because it is difficult to get users that you can study. Like it or not, 49 people is actually a pretty big study relative to what is out there. For better or for worse, I have seen much smaller studies accepted/published by top tier conferences.

Re: Study of 49 programmers: static type system had no effect on development time

#185

Earlier quoted context omitted.

Sure but remember most static languages are 20+ times faster than Ruby so even with compile times you might still come out way ahead.

Ah, but a lot of bugfixes are developed by making small changes to understand better what is going on internally during the bug symptom, and there the compile time is more important than the compile/test time.

True, and languages that are slow to compile like C++ really suffer here. But Java and Go compile so quickly it's hardly an issue.

Re: Study of 49 programmers: static type system had no effect on development time

#186
post #181

Earlier quoted context omitted.

I disagree. There's simply no way that the IDE can know everything about a variable without running the code and I don't believe that eclipse does this. It's ok at refactoring but it breaks down all the time for me, renaming unrelated variables or missing cases. I don't believe it can handle kwargs for example (no computer in front of me, feel free to prove me wrong)

> There's simply no way that the IDE can know everything about a variable without running the code Or with. With dynamic typing and dynamic name resolution such as in Python, there's no way to know with certainty, even if you run it.

In theory, you're right. In practical, day-to-day programming, an IDE can get it right the vast majority of times and do exactly the right thing. See a previous post of mine: http://news.ycombinator.com/item?id=4037602

Re: Study of 49 programmers: static type system had no effect on development time

#187

Earlier quoted context omitted.

> a REPL. Just give it a whirl and see what you get. In a large system you might have to jump through a lot of hoops to get an accurate result from the REPL. What if the thing you're trying to puzzle out is 20 call levels deep? As a new Ruby dev I struggle with this.

If it is a pure function it makes the call depth irrelevant. While not always the case, it seems to be pretty common in Ruby development to keep things as pure as possible.

No, it's not irrelevant. If you're trying to figure out what gets passed up the call stack, you need to trace it through. Being able to plug in your own values into a single method call via the REPL isn't helpful if you're trying to analyze what really happens when it runs. Either you need to run it under a debugger, or manually trace it through. In a static language you just have to read the type signatures.

Re: Study of 49 programmers: static type system had no effect on development time

#188
post #181

Earlier quoted context omitted.

> There's simply no way that the IDE can know everything about a variable without running the code Or with. With dynamic typing and dynamic name resolution such as in Python, there's no way to know with certainty, even if you run it.

In theory, you're right. In practical, day-to-day programming, an IDE can get it right the vast majority of times and do exactly the right thing. See a previous post of mine: http://news.ycombinator.com/item?id=4037602

I believe that "works almost every time" is great, but that last inch is also meaningful. Knowing you can trust your IDE's refactorings is reassuring and allows you to dare do things you might otherwise not dare.

Re: Study of 49 programmers: static type system had no effect on development time

#189

Earlier quoted context omitted.

If it is a pure function it makes the call depth irrelevant. While not always the case, it seems to be pretty common in Ruby development to keep things as pure as possible.

No, it's not irrelevant. If you're trying to figure out what gets passed up the call stack, you need to trace it through. Being able to plug in your own values into a single method call via the REPL isn't helpful if you're trying to analyze what really happens when it runs. Either you need to run it under a debugger, or manually trace it through. In a static language you just have to read the type signatures.

As mentioned by JackC, if you need to understand the context in which a method is called, use a REPL. But to understand what a pure method does should be context free, by definition.

Re: Study of 49 programmers: static type system had no effect on development time

#190
post #73

Earlier quoted context omitted.

You are hitting exactly the main point. Dynamic languages are very good for prototyping or small scale projects. But they fail to address the context of programming large scale applications with teams distributed across multiple sites.

I agree dynamic languages result in smaller codebases, but that's only because they tend to be so much more concise than most statically typed languages. Also, as for large and complex projects done by distributed teams, I don't have to point much further than Django or Plone to prove dynamic typing works well in that context.

Django and Plone are very tiny code bases compared with the projects I work with.

- Big consultancy company working with lots for Fortune 500 company groups;

- At least 3 development sites active at any time;

- Some projects can have 100+ active developers across sites;

- Several MB of written source code, plus many modules generated via specific DSLs or code generation tools

- The typical enterprise architectures

- Lots of crappy developers in some of the teams

The implications of static typing helps keeping the possible damages under control.

Post reply on HN