3 ms·

A big advantage of unsound types is versioning. IE you can add some member variables/methods to a structure/class and users of that library that were written wi

by rb808 9y ago

A big advantage of unsound types is versioning. IE you can add some member variables/methods to a structure/class and users of that library that were written with the old version still work without trouble, recompilation or redeploying. Of course if you remove the variable they're in trouble but removing can be avoided for that reason.

galaxyLogic 9y ago
In this sense typing is like unit-testing it would seem. You can make your program "better" by adding more unit-tests to it. But more tests you have the more work it will be to modify your tests, to accommodate the changes in your program. The more strict your type-system is the more things you can prove and thus understand about your program. But if you need to change your program it may no longer compile with the existing types. Does your type-system then make it easy to change your types so they reflect your new program? Now assumably when you are developing a new program it is changing all the time. If you fix its types early doesn't it actually make it more work to create your program? Once your application is done and works and is big it is essential that it is "typed" so that you can see what changes don't require changes in the types vs. what changes would require a lot of rewriting of the types all over the place. I think the fact that many useful programs are written in dynamically typed languages speaks for this. Small programs don't need types. Does this mean that optional typing is a good feature?
- pas 9y ago
  I usually find a lot more serious bugs in quick and dirty scripts, than in big systems, regardless of language. (Naturally, big systems have already survived the small PoC phase, plus usually big things are viewed as complex, whereas small scripts are dangerously innocent looking.) So in that way things like Ammonite (easy scripting using Scala) seem very useful - even if the runtime requirements are a lot heavier, than using bash (or python). Furthermore, usually development uses type system as a tool, so it'd be hard to add typing when it's done. (I mean, usually functional doneness is checked or "asserted" in a large part through types, and unit/integration tests help with the rest.) So in this sense typing doesn't add more development time. It just makes problems a lot more explicit, so you know you're not done yet.
  - galaxyLogic 9y ago
    Explicitly declared types are like anchors. They make it harder to change the program to be a different program. In many cases this is good since it tells whether a change breaks things or not. But it does add to the "mass" of your program, makes it harder to change its direction. Your declared types are the shared "language" under your program. It is much harder to change the language that what is said in it. Changing the language would actually change the MEANING of what has already been said.
- lmm 9y ago
  > Does your type-system then make it easy to change your types so they reflect your new program? Yes. The type system in fact makes it easier to make this kind of change, because when I change one of my assumptions (e.g. I say "the input list to this function must always be non-empty") the compiler tells me exactly where I need to make a corresponding change. > Now assumably when you are developing a new program it is changing all the time. If you fix its types early doesn't it actually make it more work to create your program? Fixing the types early would indeed be a disaster, but why would you ever do that? Types are something that evolve and change as the program does, just like e.g. variable names.

by rb808 9y ago

galaxyLogic 9y ago

In this sense typing is like unit-testing it would seem. You can make your program "better" by adding more unit-tests to it. But more tests you have the more work it will be to modify your tests, to accommodate the changes in your program. The more strict your type-system is the more things you can prove and thus understand about your program. But if you need to change your program it may no longer compile with the existing types. Does your type-system then make it easy to change your types so they reflect your new program? Now assumably when you are developing a new program it is changing all the time. If you fix its types early doesn't it actually make it more work to create your program? Once your application is done and works and is big it is essential that it is "typed" so that you can see what changes don't require changes in the types vs. what changes would require a lot of rewriting of the types all over the place. I think the fact that many useful programs are written in dynamically typed languages speaks for this. Small programs don't need types. Does this mean that optional typing is a good feature?

pas 9y ago
I usually find a lot more serious bugs in quick and dirty scripts, than in big systems, regardless of language. (Naturally, big systems have already survived the small PoC phase, plus usually big things are viewed as complex, whereas small scripts are dangerously innocent looking.) So in that way things like Ammonite (easy scripting using Scala) seem very useful - even if the runtime requirements are a lot heavier, than using bash (or python). Furthermore, usually development uses type system as a tool, so it'd be hard to add typing when it's done. (I mean, usually functional doneness is checked or "asserted" in a large part through types, and unit/integration tests help with the rest.) So in this sense typing doesn't add more development time. It just makes problems a lot more explicit, so you know you're not done yet.
- galaxyLogic 9y ago
  Explicitly declared types are like anchors. They make it harder to change the program to be a different program. In many cases this is good since it tells whether a change breaks things or not. But it does add to the "mass" of your program, makes it harder to change its direction. Your declared types are the shared "language" under your program. It is much harder to change the language that what is said in it. Changing the language would actually change the MEANING of what has already been said.
lmm 9y ago
> Does your type-system then make it easy to change your types so they reflect your new program? Yes. The type system in fact makes it easier to make this kind of change, because when I change one of my assumptions (e.g. I say "the input list to this function must always be non-empty") the compiler tells me exactly where I need to make a corresponding change. > Now assumably when you are developing a new program it is changing all the time. If you fix its types early doesn't it actually make it more work to create your program? Fixing the types early would indeed be a disaster, but why would you ever do that? Types are something that evolve and change as the program does, just like e.g. variable names.