News for hackers. Stuff that matters.
Re:Summer of Programming Languages by lmm on Monday July 07, 2014 @03:07AM (#7997481)
Any property that you can actually be confident about, you can encode into the type system. If you care that x ^ (y - z) is an integer, you'd better have some reason to believe that y > z. If you don't care or can't be sure, let x ^ (y - z) return Integer | Rational, and pattern-match for the cases (or treat them as some supertype, Numeric or some such). Or if you really can't figure out the proof but still think it's correct, you can cast, and then your program will error out at runtime if you're wrong, which is at least safe.

In a dynamic language, your mistake passes silently; the result you thought was an integer is actually a fraction, but your program carries on going. Maybe it turns it into a string and uses it as a file path, so something you thought was a simple filename has a slash in it. Maybe that breaks your security model. Pretty unlikely in this specific case, but that's how bugs happen.

Re:Summer of Programming Languages by jballanc on Monday July 07, 2014 @03:34AM (#7997555)
Right, but it's also much simpler and faster for the programmer to write one function with one return type, and later modify it to add a return type if the requirements change. I think this is obviously why dynamic languages rose in prominence coincidentally with the rise in rapid prototyping and agile development. That said, this is also why large companies with codebases that need to be maintained over multiple decades will always go with static languages.

What really interests me are languages like Julia or Dart, with their gradual typing, or Clojure and core.typed. You retain the flexibility and speed of development of a dynamic language, with the possibility of later adding type safety guarantees to your code without having to rewrite it from scratch.

Re:Summer of Programming Languages by steveklabnik on Monday July 07, 2014 @11:12AM (#7999247)
> it's also much simpler and faster for the programmer to write one function with one return type, and later modify it to add a return type if the requirements change.

How is this different? When you compile, your compiler will say "Hey, the requirements have changed, your code is wrong here, here, here, and here," and you modify those things, and you're done.

Re:Summer of Programming Languages by tormeh on Monday July 07, 2014 @02:50PM (#8000577)
....and then you've forgot what you were actually trying to solve.
Re:Summer of Programming Languages by the_af on Monday July 07, 2014 @05:45PM (#8001671)
What is the alternative? You change the code, the behavior gets changed but the compiler doesn't warn you. At this point you have two possible paths:

1- You wrote tests which start failing. You must now spend time changing them. You don't manage to avoid working in order fix your safety net (be it static type checking or your test suite).

2- You didn't write the right tests, and don't notice the change in behavior. The program later fails in production.

Re:Summer of Programming Languages by steveklabnik on Monday July 07, 2014 @03:05PM (#8000664)
Why? Aren't you trying to solve the change in interface? And wouldn't you be making the same changes in a dynamically typed language?
Re:Summer of Programming Languages by lmm on Monday July 07, 2014 @06:15PM (#8001882)
I find the type system a great help with remembering what I was actually trying to solve. I can "start at the end" and then work backwards, solving one compile error at a time until there aren't any left, at which point I'll know I've done what I wanted to.
Re:Summer of Programming Languages by cousin_it on Monday July 07, 2014 @07:25AM (#7998225)
> Any property that you can actually be confident about, you can encode into the type system.

The big theoretical drawback is that you get an unbounded increase in program length. The reason is that programs in a typed language are proofs, and proof length cannot be bounded above by any computable function of proposition length.

The big practical drawback is that we just don't know how to explain proofs to a computer very well.