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

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

cs.washington.edu

Post reply on HN
Print view View original

161–170 of 192 posts

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

#161

Post by JackC »

kaffeinecoma wrote: post #142
phamilton wrote: post #33

I recently talked to a friend of mine who expressed the frustration of not knowing what a function returns because it's a language without static typing. It was something I hadn't thought of before personally. I thought about it a bit and realized that as a Ruby programmer, I depended on two things to figure out what a function returns, and neither is the source or documentation (most of the time at least): 1) a REPL…

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

In python if I was trying to figure out something complex 20 levels deep, I would stick in an "import pdb; pdb.set_trace()" to get a REPL at that spot. There's probably an equivalent for Ruby?

(Off-topic, the werkzeug debugger even lets you debug browser apps by jumping into a REPL anywhere in the stack trace, in the browser, after an exception is thrown. I think it also has a command that bakes you a pie.)

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

#162

Post by silverlake »

rpearl wrote: post #155
silverlake wrote: post #133

Earlier quoted context omitted.

No study can control all the variables enough to convince a fanboy that his favorite language isn't the greatest ever. However, the current state of PL research is as close to astrology as you can get. Why are we working on type systems and modules and concurrency primitives et. al. without a scrap of evidence that any of it contributes to programmer productivity? There's no science there. In fact, everyone here shou…

PL research is not necessarily for "contributing to programmer productivity." Formalization of various programming language concepts into a type system[0] allows researchers to apply analysis and verification techniques. The simplest example I can think of is the Maybe type. Instead of having null pointers and, if you forget to check for NULL, getting a runtime error (segfault, NullPointerException, whatever), instea…

You say: "when features look like they'd be useful to integrate into languages". How do you know a feature would be "useful" without compelling evidence that this is really a problem for programmers? Now you're back to the original problem of figuring out what the most significant problems are for programmers. Wouldn't it be better to figure this out BEFORE PL people plunge into a particular topic?

Remember all the research done on typestates? The motivation section of those papers was usually a few paragraphs of total BS. AFAIK, there was no real data nor experiment that demonstrated this was a real problem for professional programmers.

FYI: I like static type systems and used Haskell et. al. But no one has demonstrated that it is better than even Visual Basic!

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

#163

Post by phamilton »

kaffeinecoma wrote: post #142
phamilton wrote: post #33

I recently talked to a friend of mine who expressed the frustration of not knowing what a function returns because it's a language without static typing. It was something I hadn't thought of before personally. I thought about it a bit and realized that as a Ruby programmer, I depended on two things to figure out what a function returns, and neither is the source or documentation (most of the time at least): 1) a REPL…

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

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

#164

Post by silverlake »

bunderbunder wrote: post #150
silverlake wrote: post #133

Earlier quoted context omitted.

No study can control all the variables enough to convince a fanboy that his favorite language isn't the greatest ever. However, the current state of PL research is as close to astrology as you can get. Why are we working on type systems and modules and concurrency primitives et. al. without a scrap of evidence that any of it contributes to programmer productivity? There's no science there. In fact, everyone here shou…

Well, one thought that comes to mind is that the topic is essentially a subset of ergonomics, so perhaps experimental protocols should take a few more cues from ergonomics research. For example, controlling variables has to be done by constructing artificial systems from the ground up. You can't just pull two commercial products off the shelf and then pretend you're examining the impact of only one of the hundered di…

Did you even read the linked paper? They did exactly what you described.

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

#165

Post by ww520 »

phamilton wrote: post #160
ww520 wrote: post #84

Earlier quoted context omitted.

I think we are talking about different things. Duck-typing doesn't help in depicting what the return type of a function is when looking at the function signature only. You need to look at the function implementation (the actual duck) to tell what the return type is.

My point I guess was that with proper abstractions and duck typing you really don't have to care about the type. I only notice something isn't a duck when I try to use it like a duck and it fails - which is surprisingly infrequent.

It becomes difficult to tell it's a duck when reading code, which was the original complaint. Duck type works when you actually try calling it.

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

#166

Post by cageface »

rbanffy wrote: post #151
cageface wrote: post #92

Earlier quoted context omitted.

Static type systems don't excuse you from writing tests. But they do effectively write a whole class of tests for you, and run them much faster and give you more precise errors than manual testing ever will. People complain about C++ compile times but I've heard of big Ruby projects with test suites that take 20+ hours to run.

> I've heard of big Ruby projects with test suites that take 20+ hours to run. I'd assume those tests go well beyond type checking.

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

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

#167

Post by rpearl »

silverlake wrote: post #162
rpearl wrote: post #155

Earlier quoted context omitted.

PL research is not necessarily for "contributing to programmer productivity." Formalization of various programming language concepts into a type system[0] allows researchers to apply analysis and verification techniques. The simplest example I can think of is the Maybe type. Instead of having null pointers and, if you forget to check for NULL, getting a runtime error (segfault, NullPointerException, whatever), instea…

You say: "when features look like they'd be useful to integrate into languages". How do you know a feature would be "useful" without compelling evidence that this is really a problem for programmers? Now you're back to the original problem of figuring out what the most significant problems are for programmers. Wouldn't it be better to figure this out BEFORE PL people plunge into a particular topic? Remember all the r…

Not really. The research, again, isn't in programmer usability. It's in formal logic and analysis of the semantics of computer programs. Benefits for programmers are just a side-benefit. The goal is advancing humanity's understanding of computer science, not in helping programmers, although sometimes the two goals are somewhat linked and deeper understanding occasionally yields industry benefits. In my example, and in many instances of expressive type systems, research has yielded tangible benefits for industry.

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

#168

Post by barik »

klodolph wrote: post #146
jbranchaud wrote: post #111

Earlier quoted context omitted.

"Almost no CS papers I've read have contained empirical studies." You aren't reading the right papers then. At least in Software Engineering, you can't get into the main conferences (ICSE and FSE) without a pretty significant empirical study.

Yes, but that's the main difference between computer science and software engineering.

That's a broad brush, and though it's probably a good categorization, I don't find this distinction to be all that useful as a boundary. For instance, the field of artificial intelligence and cognitive psychology branched at one point, so much of my work in cognitive architecture and algorithmic modeling necessitates user studies. One would be hard-pressed to bucket AI into software engineering though. Likewise, in machine learning, I've seen a push from classical data-driven to modern "data-informed" approaches to analyzing these results. Computational linguistics (NLP) and computational narrative are yet additional examples of fields that often requires user studies or other empirical data.

More to the point, the distinction of what is and isn't computer science has become even more blurry in the research community because research in itself has become more inter-disciplinary. There seems to be little to gain from attempting to "bucket" research into distinct taxonomies.

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

#169

Post by aangjie »

pcopley wrote: post #115
aangjie wrote: post #38

Earlier quoted context omitted.

I second that.It's one of the reasons i quit my day job to do a Master's degree...though i chose a naive enough college and course that am now back to a programming job where i am surrounded by the same type of crowd again.

I'm curious what your Master's is in and what "type" you're surrounded by.

Oh. Sorry, for that snarky reply(tired i guess). I have a master's in cognitive science(from india). And currently a python programmer here. Mainly because there aren't that many jobs(in cog. sci.) , here and i was not focused enough to get published in a journal during my master's. As for types, well, one ex: is a situation where i was trying to defend my choice of Dvorak kb saying usability and got a dismissive, snorty laugh as a response.

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

#170

Post by akkartik »

weavejester wrote: post #157
pjmlp wrote: 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.

How does static typing help that?

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.

Post reply on HN