91–100 of 192 posts
I tend to find the strongest proponents of static typing are the least familiar with dynamic languages
On the rare occasion you really need the kind of anything-goes dynamism of Ruby/Python/JS you can just roll your own dispatch tables.
I'm still torn between dynamic and static typing. The main disadvantage of dynamic typing for me is the lack of verifiable documentation about what data a function needs, and which data comes out of it. This becomes a problem when a) the data is complex (e.g. dictionary of lists of items with certain properties) b) I haven't looked at the function for a while. In those cases, I find statically typed code easier to re…
I use tests for documentation. They seem like more work at the start, but they're more flexible. You can self-document things with tests that you cannot with just types. For example, here are some tests from the lisp interpreter I've been working on: http://github.com/akkartik/wart/blob/8a8cf96816/030.test You're right that tests aren't close to code. But that can be good or bad. Since it's not next to the code it ca…
People complain about C++ compile times but I've heard of big Ruby projects with test suites that take 20+ hours to run.
It seems to be very basic static typing along the lines what Java or C has stashed on top an Smalltalkesque object-oriented language, so I am not surprised, the many years I used dynamically typed languages I maybe once or twice had a type error of the kind "confusing int with string" (e.g. when selecting a number from database and it being returned as string). For the benefits of static typing I would rather look in…
Earlier quoted context omitted.
No, it isn't. Please read the paper and not the HN title. The paper clearly states that static typing slowed development time down .
"In the experiments the existence of the static type system has neither a positive nor a negative impact on an application's development time (under the conditions of the experiment)." Maybe the abstract is lying, but that seems to agree with my original premise. That is, the type system had no effect on development time. Now, the paper makes no comment either way--all it says is that the type system did not have an…
To quote:
We measured two different points in the development: first, the development time until a minimal scanner has been implemented, and second the quality of the resulting software measured by the number of successful test cases fulfilled by the parser. In none of these measured points the use of a static type system turned out to have a successful impact. In the first case, the use of a statically typed programming language had a significant negative impact, in the latter one, no significant difference could be measured.
Earlier quoted context omitted.
Please read the paper and not the HN title. The paper's title is casting doubts on the positive impact of statically typed languages as they had a negative impact on development time. (though not quality)
From the very first paragraph : In the experiments the existence of the static type system has neither a positive nor a negative impact on an application's development time (under the conditions of the experiment). What's the point of dynamic languages if they don't even make the initial implementation faster? They're certainly harder to maintain afterwards.
We measured two different points in the development: first, the development time until a minimal scanner has been implemented, and second the quality of the resulting software measured by the number of successful test cases fulfilled by the parser. In none of these measured points the use of a static type system turned out to have a successful impact. In the first case, the use of a statically typed programming language had a significant negative impact, in the latter one, no significant difference could be measured.
I'm still torn between dynamic and static typing. The main disadvantage of dynamic typing for me is the lack of verifiable documentation about what data a function needs, and which data comes out of it. This becomes a problem when a) the data is complex (e.g. dictionary of lists of items with certain properties) b) I haven't looked at the function for a while. In those cases, I find statically typed code easier to re…
That programmer quality shows way stronger effects than the measured effect of a typing system would suggest to me that
- the measurement was flawed?
- programmer ability beats language choice by orders of magnitude?
Or do I make a category error here?
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'm betting youtube is bigger than all of your sites combined, and they use python.
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".
* The whole api consisted of 14 classes, which makes the conclusion that static typing doesn't help with API discoverability somewhat moot.
* We are not talking about Haskell, Scala or even Java/C++ flavor of static typing. The statically typed language offers no generics, no support for encapsulation, no type inference etc.
* IDE support seems to be absolutely minimal.
A methodical problem is that they seem to skip over the abysmal success rate: Only one(!) guy or gal was able to get 100%, more than halve of them was unable to implement a meaningful parser at all. To be honest, it looks a little bit like the subjects were overwhelmed by the unfamiliar syntax and/or most of them where really inexperienced (the paper says that none of them ever implemented a scanner or parser).