3 ms·

The study the OP references (from the original talk) seems suspect to me; in particular, the fact that the researcher created both a static and a dynamic versio

The study the OP references (from the original talk) seems suspect to me; in particular, the fact that the researcher created both a static and a dynamic version of his own language. Generalizations about the time required to "get stuff done" in all (or even most) statically/dynamically typed languages feel unwarranted. And then there are statements like this: "he found [that] it took less time to find [type] errors than it did to write the type safe code in the first place." Maybe that's an indication that his homegrown statically typed language was a crappy language, rather than exposing some fundamental truth about statically typed languages in general?

kd0amg 11y ago
The first thing I wondered about on seeing that claim was what sort of error reporting was implemented in the type checker and the (dynamic) language runtime. Comparison against C for "what does static typing offer" also feels like something of a strawman.
pekk 11y ago
> Maybe that's an indication that his homegrown [...] language was a crappy language, rather than exposing some fundamental truth about [...] languages in general? Can you come around and make this same argument any time someone makes a blanket statement about static languages being unconditionally better than dynamic ones?
- dgritsko 11y ago
  I guess what I was hoping to emphasize is that the number of variables involved in trying to quantify something like this make it difficult (probably impossible) to have an accurate comparison -- even more so when attempting to generalize the results of those comparisons to larger categories of programming languages.
ianamartin 11y ago
I agree that studies of the form, "How long does it take to implement some app A in language X" are asking the wrong question. I thought we all knew and agreed that the difficult part of most applications is maintenance. How does static or non-static affect a new hire's ability to get up to speed and support an app? How does it affect long-term maintenance, refactoring, adding features, and fixing bugs? I'm not entirely sure how to answer that question, but I'm not convinced that controlled studies will point to an answer. It might be interesting to look at corporate metadata and try to find how how much companies spend over the lifecycle of an application on the whole development and maintenance of a project. See if you can find projects with enough similarities to warrant a comparison and compare a Java app with a Python app. Probably impossible, honestly. I don't have a strong opinion on the matter. In my experience, th e design and leadership of a project have a far bigger impact on the ease of development and maintenance than the type system. I've seen very large but very elegant C# programs that were a pleasure to work on and maintain. I've seen Python web systems that are an absolute nightmare to work on and reason about. Probably most people here have experiences going both ways with different type systems. I blame the developer for god-awful messes and praise the developer when I see clean, sensible code. I never blame the language. Except for JavaScript. I will always blame JavaScript. Hell, JavaScript is probably what's really causing global warming. In general, a clear head and some discipline count more for code quality than any type system, and the lack of either definitely does more damage than any type system can. But I'd go along with the idea that statically typed languages force more discipline on younger developers who haven't yet got the experience to even know what clear-headed ness even means. Working in C# was a great experience for me coming from a self taught Python background, no question about it. It also improved and helped me structure my Python code, and becoming better at designing good Python code in turn helped me write better C#. There can be a virtuous cycle in working with different languages and type systems.
mannykannot 11y ago
Furthermore, if the programs were small, it is likely that their authors would have the whole thing in their mental 'working memory', and therefore likely to catch type errors as they made them. "he found [that] it took less time to find [type] errors than it did to write the type safe code in the first place." But type errors in dynamically-typed programs are found by testing, and testing time grows much faster than linearly with respect to program size, while the amount of type information grows approximately linearly (or perhaps less than linearly, if Halstead's relationship between program length and the number of distinct operators and operands holds.) https://en.wikipedia.org/wiki/Halstead_complexity_measures https://en.wikipedia.org/wiki/Halstead_complexity_measures
bmm6o 11y ago
I haven't read that paper yet, but this sort of test seems like it should have the least noise in the results. I'm also surprised that the solutions took longer in the typed language, but it really depends on how much cognitive overhead the language imposes. For instance, modern typed languages are moving to implicit types for local variables, while the alternative can be a lot of pointless typing (on the keyboard) [though there are debates to be had about making some of those types explicit to aid readability]. If the languages really are similar, the only types you have to specify are for member variables and functions, right?

kd0amg 11y ago

The first thing I wondered about on seeing that claim was what sort of error reporting was implemented in the type checker and the (dynamic) language runtime. Comparison against C for "what does static typing offer" also feels like something of a strawman.

pekk 11y ago

> Maybe that's an indication that his homegrown [...] language was a crappy language, rather than exposing some fundamental truth about [...] languages in general? Can you come around and make this same argument any time someone makes a blanket statement about static languages being unconditionally better than dynamic ones?

dgritsko 11y ago
I guess what I was hoping to emphasize is that the number of variables involved in trying to quantify something like this make it difficult (probably impossible) to have an accurate comparison -- even more so when attempting to generalize the results of those comparisons to larger categories of programming languages.

ianamartin 11y ago

I agree that studies of the form, "How long does it take to implement some app A in language X" are asking the wrong question. I thought we all knew and agreed that the difficult part of most applications is maintenance. How does static or non-static affect a new hire's ability to get up to speed and support an app? How does it affect long-term maintenance, refactoring, adding features, and fixing bugs? I'm not entirely sure how to answer that question, but I'm not convinced that controlled studies will point to an answer. It might be interesting to look at corporate metadata and try to find how how much companies spend over the lifecycle of an application on the whole development and maintenance of a project. See if you can find projects with enough similarities to warrant a comparison and compare a Java app with a Python app. Probably impossible, honestly. I don't have a strong opinion on the matter. In my experience, th e design and leadership of a project have a far bigger impact on the ease of development and maintenance than the type system. I've seen very large but very elegant C# programs that were a pleasure to work on and maintain. I've seen Python web systems that are an absolute nightmare to work on and reason about. Probably most people here have experiences going both ways with different type systems. I blame the developer for god-awful messes and praise the developer when I see clean, sensible code. I never blame the language. Except for JavaScript. I will always blame JavaScript. Hell, JavaScript is probably what's really causing global warming. In general, a clear head and some discipline count more for code quality than any type system, and the lack of either definitely does more damage than any type system can. But I'd go along with the idea that statically typed languages force more discipline on younger developers who haven't yet got the experience to even know what clear-headed ness even means. Working in C# was a great experience for me coming from a self taught Python background, no question about it. It also improved and helped me structure my Python code, and becoming better at designing good Python code in turn helped me write better C#. There can be a virtuous cycle in working with different languages and type systems.

mannykannot 11y ago

Furthermore, if the programs were small, it is likely that their authors would have the whole thing in their mental 'working memory', and therefore likely to catch type errors as they made them. "he found [that] it took less time to find [type] errors than it did to write the type safe code in the first place." But type errors in dynamically-typed programs are found by testing, and testing time grows much faster than linearly with respect to program size, while the amount of type information grows approximately linearly (or perhaps less than linearly, if Halstead's relationship between program length and the number of distinct operators and operands holds.) https://en.wikipedia.org/wiki/Halstead_complexity_measures https://en.wikipedia.org/wiki/Halstead_complexity_measures

bmm6o 11y ago

I haven't read that paper yet, but this sort of test seems like it should have the least noise in the results. I'm also surprised that the solutions took longer in the typed language, but it really depends on how much cognitive overhead the language imposes. For instance, modern typed languages are moving to implicit types for local variables, while the alternative can be a lot of pointless typing (on the keyboard) [though there are debates to be had about making some of those types explicit to aid readability]. If the languages really are similar, the only types you have to specify are for member variables and functions, right?