Development time with static languages is not an issue.
Try comparing the time one needs to change the codebase written in ML and the one written in Lisp and come back. It is experimentation and change that is slow in static typing.
Study of 49 programmers: static type system had no effect on development time
41–50 of 192 posts
Re: Study of 49 programmers: static type system had no effect on development time
#42In my own experience: if I write dynamic code I'm still thinking of types. Especially in Python.. What's mutable, what isn't... This is what my professors at school say too. Less typing (pressing keys) doesn't make you think faster!
Seconded. Even though i write python code, i am still thinking of types. Infact, it's one of my gripes with the language. There are some tired mental states, when i don't think/forget to think about types, but just write and call functions. It's at those times that i find having to go back and read the original function for a type or having to go to REPL for testing the type painful. I would be happy to have a compiler tell me what type is expected instead. I guess more experience will lead me to infer this from the actual error message itself.(ex: Nonetype has no function iter)
Re: Study of 49 programmers: static type system had no effect on development time
#43Studying individuals is the wrong experiment. Static typing benefits tooling most when you have larger groups of programmers who much collaborate, often asynchronously. It's easy to hold a mental model of the code you write in your head and minimize mistakes, it's harder to hold a mental model of a larger program consisting of code written by many programmers. I'd like to see them hand a pre-written codebase of say,…
> Studying individuals is the wrong experiment. Static typing benefits tooling most when you have larger groups of programmers who much collaborate, often asynchronously. Absolutely. And also: static typing benefits is not about "development time" but about maintenance, adding stuff, refactoring etc. If anything, dynamic typing would be expected to lead to faster development time, which is also why it's used in most…
i agree totally with both parents -- i wanted to comment the same...
static typing would more benefit:
* large groups of programmers
* large codebases
* maintenance (which is usually taking more resources then the initial development of a large code base)
aditionally i've come to believe that not all static typing is created equal. most allow `null` to be returned instead of adhering to the type, then some have exceptions and not many languages type side effects (like IO). i'm basically saying that C/C++/Java/C#'s kind of typing is not Haskell's kind of typing, and that the potential gains from Haskell's type system are much bigger on the long run (while it also comes with a steeper learning curve).
Re: Study of 49 programmers: static type system had no effect on development time
#4449 undergraduate students working independently on a small project over the course of a single week using a previously unseen language with no consideration of the performance or maintainability of the resulting code. I can't see how there are any meaningful conclusions to be drawn from this study other than "inexperienced programmers find learning new dynamically typed languages easier".
You seem to be subtly implying something about people that use dynamic languages.
Not at all. When learning any new programming language there's going to be a period where you're working by trial and error. Removing compile-time typing generally means less syntax to learn which makes the feedback loop tighter which I would imagine gets you the point of familiarity quicker. The study seems to back that idea, but not much more.
Re: Study of 49 programmers: static type system had no effect on development time
#45so, by swiching from python to haskell, you can get code that's 20x faster for no extra development time? sounds like a win to me. (cherry picked shootout data - http://shootout.alioth.debian.org/u32q/which-programming-lan... )
only 20x? What happens when you reevaluate it with the python code not having any pieces that are C under the covers? (my understanding that a lot of python idioms for fast code basically turn into ah "use the approach that pushes as much work into C as possible")
Comparing favorably against a subset of a language that noone uses as such sounds pretty pointless. More interesting would be a comparison with pypy.
Re: Study of 49 programmers: static type system had no effect on development time
#46Absence of evidence is not evidence of absence.
Re: Study of 49 programmers: static type system had no effect on development time
#47The 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…
Emphatic upvote.
Software development is so complicated that there is always an endless supply of objections to fire at any study at odds with one's beliefs. And that is exactly how all these discussions go. All we're doing is repeating shibboleths.
The most interesting studies would be ones that changed somebody's beliefs. That doesn't happen very often in our field. Does it ever?
Re: Study of 49 programmers: static type system had no effect on development time
#48This study, while perhaps not very relevant to real world software engineering (development, maintenance, refactoring), seems to show that there when developers design code and applications, there's little difference for them between using dynamically or statically typed languages. And that's interesting, because it implies that the way developers think about code is somehow type independent.
Re: Study of 49 programmers: static type system had no effect on development time
#49Earlier quoted context omitted.
only 20x? What happens when you reevaluate it with the python code not having any pieces that are C under the covers? (my understanding that a lot of python idioms for fast code basically turn into ah "use the approach that pushes as much work into C as possible")
Comparing favorably against a subset of a language that noone uses as such sounds pretty pointless. More interesting would be a comparison with pypy.
which, FWIW, usually makes my typical code run 2x to 10x times faster than CPy
Re: Study of 49 programmers: static type system had no effect on development time
#50I 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…
So you basically put type information in the names. That's typing in a sense.
I see where you're going but thats not really what we're doing with that ... @user.posts actually returns an array of posts and @user.posts.first returns an actual Post object.
You could also change @user.posts to be @user.contributions, for example, and that would hide the fact that contributions was just an array of Post objects.