131–140 of 276 posts
I'm convinced that dynamically typed languages are a transitional technology that will be superseded once we develop type systems that are both usefully strict but also flexible. After over ten years working in dynamic languages I'm very happy to have a compiler on my side again.
Earlier quoted context omitted.
No, I am saying your strawman is a strawman. You were claiming static typing doesn't help since a string can contain a bad query. Now you are suggesting that you wouldn't write such code in a dynamically typed language anyways? Then why did you offer it as an example of how static typing doesn't help. Of course you can make sure you never actually run the bad query with dynamic typing. I assumed it was obvious when t…
> Now you are suggesting that you wouldn't write such code in a dynamically typed language anyways? I never suggested that...? > With a statically typed language, when you make the error, you get told about it by the compiler. With a dynamically typed language, you find out about the error later, when that code actually runs. > static typing enforces that you always use that function, and can't forget and accidently…
You mean like the validation you get when you compile a program?
Yes, a statically typed program that never gets checked is strictly worse than a dynamic program, but that's the whole point of the type system: you can check it. This argument is a strawman because nearly every language with a static type system includes a validation step (maybe Dart is an up-and-coming counterexample).
Regarding bugs, I think it's clear that static typing does detect more errors - the issue is whether it's worth the trouble. I think a more significant difference is the inertia of the codebase, how difficult it is to change. Static types make it harder to evolve interfaces; but unit tests make it even harder. But both the above are just fiddling: the real advantage of static typing is runtime speed; the advantage of…
Have you used Haskell? Speed is just a (nice) bonus. Type safety is not about speed at all.
And I am much more productive in Haskell than I could be in a dynamically typed language. I can turn the code base inside out, and trust the type system to guide me to everywhere that needs to be fixed. When I compile it, it almost always works. I barely have to test anything.
The sample size of this study is statistically too insignificant to draw the conclusions given. The counterfactuals to the claims of dynamic type advocates were already true and provable, so even if the sample size of the codebases studied were statistically significant (not to mention vetted for quality of unit test as well as coverage ) the conclusions are nevertheless trivial. In addition, the hidden assumption is…
"Based on these results, the conclusion can be reached that while unit testing can detect some type errors, in practice it is an inadequate replacement for static type checking."
As I've already pointed out, this seems to me an ambitious and over-reaching conclusion, given the scope of the study.
But, equally important, it is simply an example of something that was already provable. It should be axiomatic that in principle automatically-generated validation like that provided by static typing should in theory be able to catch type errors not caught manually in a dynamic context, either for reasons of human oversight or human error.
In other words, it seems to me that all that has been done here, is to provide a few concrete examples of what was already true and uncontroversial: auto-generated coverage of specific types of validations can be more comprehensive than some human beings will be in some environments and contexts. It has not shown that the perceived benefits of dynamic typing with good unit tests are outweighed by this fact, nor that, statistically-speaking, errors of this type are common enough to warrant a preference of static typing over dynamic typing with unit tests in all contexts.
I'm convinced that dynamically typed languages are a transitional technology that will be superseded once we develop type systems that are both usefully strict but also flexible. After over ten years working in dynamic languages I'm very happy to have a compiler on my side again.
>type systems that are both usefully strict but also flexible. that's basically the design criteria behind Go's type system.
[1]: http://existentialtype.wordpress.com/2011/03/15/boolean-blin...
Earlier quoted context omitted.
That statement, though, is almost content-free. It's a truism. If you don't have type checking, then every bug has gotten past your unit tests; but some proportion may have been prevented with type checking. And vice versa. The statement doesn't say anything about the value or non-value of unit tests or type checking.
No, it's not content-free, at least when put back into context. It's like coffee. If your coffee is shitty (complect), then no amount of sugar (unit tests) or cream (type checking) will make it any better.
Earlier quoted context omitted.
I don't know how you could contrive what I said to be cognitive dissonance. If you have a team of N good programmers, you can probably write without static typing. If you have a team of N-1 good programmers and 1 bad programmer, you should really use a language static typing.
I just read the first part of your comment as "no true programmer would need no filthy static type checking". Sorry if I misunderstood. I find it hard to correlate use of static typing with development experience, that's all.
You might still use them, and there's nothing entirely wrong with that, but you probably don't need them.
This is why so many people have problems writing JavaScript.
Earlier quoted context omitted.
> That assumption isn't hidden, it is made up. By you. Not at all. The assumption is clearly implied by the conclusion of the study, which makes an unwarranted equivalence of all languages that have 'static type checking': "The translation of these four software projects from Python to Haskell proved to be an effective way of measuring the effects of applying static type checking to unit tested software." > Just beca…
>which makes an unwarranted equivalence of all languages that have 'static type checking': No it doesn't. Read what you quoted, it says nothing even remotely resembling "this benefit applies to all languages with static typing". It is testing static typing, not a specific language. It uses the best static typing system to do so. You are entirely inventing the notion that this must then apply to java. > If the study w…
Java was state of the art 20 years ago, but it's definitely not the case any more.
The author really needs to be complemented on rewriting swathes of code from Python to Haskell. In Google, in my project, we've had runtime errors in Python code, due to wrongly spelled variables(although that is a different problem), and type error, something a compiler would have caught. Strong type checking is something that I truly like about Haskell and OCaml, I'm reasonably convinced that once my program has pa…
> we've had runtime errors in Python code, due to [...] > type error, something a compiler would have caught Are wrongly spelled variable names and type errors the only runtime errors that you get? If not what percentage are they? Personally, I think that people tend to obsess about the specific type of errors because the 'solution' (static-typing) is something that already exists, whereas there is not easy solution…
Missing imports and redundant imports also go away.
Lots of lots of invariants in the program can be encoded as types, too, so any bugs relating to them go away too.
When you want parallelism, you get useful guarantees about not changing the deterministic result you had before you added parallelism.
I used to use Python, but after Haskell, there's no way I'd go back...
Earlier quoted context omitted.
Numerical algorithms suffer from a paucity of types. So either you enrich your numerical type hierarchy, or you prove an implementation matches a model, e.g. for fibonacci http://stackoverflow.com/a/8434107/83805
I don't have a response to that, other than to say, now you know why I decided to write compilers instead of pursue a graduate degree in computer science.