21–30 of 62 posts
This makes it sound as though Russel showed the system to be incomplete, and the reference to Godel's theorem in the next paragraph reinforces the confusion. Russel instead showed the system to be inconsistent, which is much worse.
Honestly, I feel like the current is going the opposite direction here. In the mid-to-late 2000s the most ascendent languages seemed to be dynamic ones. Ruby, Python, PHP, Javascript, etc. Perhaps that's web solipsism, but those are the languages I remember having the highest visibility from that time. Currently, the tide seems to be changing to towards static typing (and stronger typing). Swift, rust, go, scala, etc…
>Tests are not proofs Neither is static typing. It's a layer of protection, much like tests. >Tests are more work I don't think that's necessarily true. You still need to write tests with or without static typing. Those tests you need to write anyway will usually catch type errors in a dynamically typed language that a statically typed language picks up at compile time. The question is whether you need to write more…
Not true. The curry-howard correspondence shows the relationship between typed programs and proofs. I recommend you watch a Phillip Wadler talk about this: https://www.youtube.com/watch?v=aeRVdYN6fE8
Note: This doesn't mean that type systems can prove _all assertions_ about a program, but type systems do indeed work as provers.
> I don't think that's necessarily true. You still need to write tests with or without static typing. Those tests you need to write anyway will catch type errors in a dynamically typed language that a statically typed language picked up at compile time..
This isn't necessarily true unless you test for all inputs (which tends to be infeasible in most cases). A type system can reject inputs by virtue of their lack of conformance to a type, which eliminates the need to test them.
> The question is whether you need to write more tests and whether the greater number of tests offsets the greater amount of code you need to write to statically type your code.
I don't have any evidence to support this (if someone does or has proof to the contrary, I'd love to see it referenced here), but I believe there is almost no overhead imposed by a static type system with type inference.
> Ditto for types.
I acknowledged this above, you just removed that part from the quote. In practice I've never had a bug with the type system (that I'm aware of), while I've seen hundreds of bugs from incorrect test assertions.
Honestly, I feel like the current is going the opposite direction here. In the mid-to-late 2000s the most ascendent languages seemed to be dynamic ones. Ruby, Python, PHP, Javascript, etc. Perhaps that's web solipsism, but those are the languages I remember having the highest visibility from that time. Currently, the tide seems to be changing to towards static typing (and stronger typing). Swift, rust, go, scala, etc…
>Tests are not proofs Neither is static typing. It's a layer of protection, much like tests. >Tests are more work I don't think that's necessarily true. You still need to write tests with or without static typing. Those tests you need to write anyway will usually catch type errors in a dynamically typed language that a statically typed language picks up at compile time. The question is whether you need to write more…
> My own prediction is that TDD is the deciding factor. If this turns out to be the case, then people would reach for statically typed languages to augment & cut-down on tests. Like everyone here is saying, the pendulum is moving toward statically typed. The next generation will probably be in higher kinded types as we continue to attempt to write more generic code that cuts down on number of lines, but still preserv…
> My own prediction is that TDD is the deciding factor. If this turns out to be the case, then people would reach for statically typed languages to augment & cut-down on tests. Like everyone here is saying, the pendulum is moving toward statically typed. The next generation will probably be in higher kinded types as we continue to attempt to write more generic code that cuts down on number of lines, but still preserv…
"Clever" or "overly specialized", depending on your viewpoint.
http://conal.net/blog/posts/the-c-language-is-purely-functio...
Likewise, tests and type systems approach equivalence (especially with dependent types).
Thus the distinctions are practical rather than purely theoretical.
(1) In practice, I find the static typing approach to result in more complete "tests".
(2) In practice, I don't see people writing reusable tests when they share code with others. However static types are are shared with the user's code, thus reducing the testing they need to write themselves.
Honestly, I feel like the current is going the opposite direction here. In the mid-to-late 2000s the most ascendent languages seemed to be dynamic ones. Ruby, Python, PHP, Javascript, etc. Perhaps that's web solipsism, but those are the languages I remember having the highest visibility from that time. Currently, the tide seems to be changing to towards static typing (and stronger typing). Swift, rust, go, scala, etc…
I'd amend this to say that sometimes the compiler can prove you're calling a function with or setting a variable to an incorrectly-typed input, but at runtime a strong type system by itself doesn't prevent receiving those inputs, only executing them.
It is possible to create a programming language with semantics such that the compiler will always catch incorrectly-typed inputs, but that's a separate but related concept from the type system.
This is the man who, somewhere around 2011 I think, claimed that we might have explored the whole programming language space, and there might not be any new programming languages left to be invented. He's also the man who, going by the very post we're discussing, seems to think that having typing so restrictive that not everything is nullable by default is some sort of radical new idea. (Compare that with Tony Hoare's conference speech in 2009, in which he called inventing the null reference his billion dollar mistake, and notice that almost every modern static language provides this kind of safeguard.) So I'm not sure we should take Robert Martin's predictions for where the programming industry is going too seriously; indeed, he should perhaps learn a bit more about what is already available today before making big public predictions about tomorrow.
Honestly, I feel like the current is going the opposite direction here. In the mid-to-late 2000s the most ascendent languages seemed to be dynamic ones. Ruby, Python, PHP, Javascript, etc. Perhaps that's web solipsism, but those are the languages I remember having the highest visibility from that time. Currently, the tide seems to be changing to towards static typing (and stronger typing). Swift, rust, go, scala, etc…
>Tests are not proofs Neither is static typing. It's a layer of protection, much like tests. >Tests are more work I don't think that's necessarily true. You still need to write tests with or without static typing. Those tests you need to write anyway will usually catch type errors in a dynamically typed language that a statically typed language picks up at compile time. The question is whether you need to write more…
Neither is static typing. It's a layer of protection, much like tests.
Proofs are exactly what the results of strong static type systems give you. They can't prove everything, but they do prove certain things in all possible cases.