3 ms·

Static typing is not at all bad; usual static typing mechanisms are, due to the fact that most of them force you into designing your types before you even have

by tmcb 7y ago

Static typing is not at all bad; usual static typing mechanisms are, due to the fact that most of them force you into designing your types before you even have a working prototype. (If you should first understand your problem before you write some code or if you should use code to help you understand the problem and then write more code is up to debate, of course. Typing is an invaluable tool of thought to help you understand your problem, yes, but it is just one more tool in the toolbox.) The sad thing I noticed though is that, having hacked a mostly untyped Python code base during the last few days, making sure that all typing annotations you add to the code base are sound is a big PITA, to put it bluntly, and I would pretty much prefer to work with a statically typed language in this particular case. If your typing discipline is uncoupled from the ability to run code, people simply remove that obstacle from their way. It starts to be treated pretty much like tests and documentation: indispensable in theory, relegated to second plan in practice. So my impression is that gradual typing almost got it right, but it may do a great disservice to overall code quality as well. I am now inclined to think that some kind of barbell strategy on typing will render better results: use both a completely untyped dynamic language such as Tcl, where everything is a string, and a static, strongly typed programming language (ideally a proof assistant with dependent types). You prototype with the former and move into production after translating your solution to the latter. If you ever need to push untyped code into production, it will be obvious to everyone involved and, since it is so decoupled, it cannot affect the quality of the statically typed codebase by any chance.

sbergot 7y ago
> Static typing is not at all bad; usual static typing mechanisms are, due to the fact that most of them force you into designing your types before you even have a working prototype. > Typing is an invaluable tool of thought to help you understand your problem, yes, but it is just one more tool in the toolbox For me those two sentences contradict each others. Types force you to draw an outline of your solution. For any non trivial problem this will be a time saver even in the prototype phase.
- tmcb 7y ago
  I can't see how they do, sorry. In fact, they complement each other. The usual static typing mechanisms I mentioned force you to approach a problem with their specific mindset, very much like math problems that add unreasonable constraints to their statements in order to check if you grasped a specific concept really well. In a real world scenario you should be able to reason your way out of the problem without such artificial constraints. So it should not be a restriction to anybody if they can accurately explain a concept or implement a program without using tools such as types.
lidHanteyk 7y ago
Static typing isn't bad, but it's only as good as the type system is strong and detailed. Haskell's QuickCheck doesn't understand biases or infinite-typed values. The Hypothesis strategy of Strategies (the design pattern) is far more useful for producing serious test suites, as less time has to be spent fretting about which invariants can be hoisted to the type system.
j88439h84 7y ago
Monkeytype generates type hints from runtime observation.
zozbot234 7y ago
> use both a completely untyped dynamic language such as Tcl, where everything is a string, and a static, strongly typed programming language (ideally a proof assistant with dependent types). This is gradual typing. The real problem with gradual typing is that you largely forgo the performance advantages of static typing, since you spend a lot of compute time translating data in and out of "dynamically-typed" (i.e. tagged/runtime dispatched) representations. This is especially obvious in stringly-typed languages ala Tcl, but applies elsewhere as well.
- tmcb 7y ago
  I don’t think so. My hopes here are that, in having two orthogonal code bases in extremely different languages, there would be no chance that typed and untyped code intertwine, hence compromising typing accuracy. I regard this possibility as a serious problem with gradually typed languages, one of those that risk to be addressed with lengthy software engineering books, those to be mentioned as mandatory knowledge on every single programmer job interview by the year of 2039. But I digress. “Abrupt typing” would describe this approach more precisely, if there was such jargon. A program module has no types while it is a prototype, but it must be completely typed (which is just another term for “having its correctness proved with the best tools available at this day and age”) before it goes into production.

by tmcb 7y ago

sbergot 7y ago

> Static typing is not at all bad; usual static typing mechanisms are, due to the fact that most of them force you into designing your types before you even have a working prototype. > Typing is an invaluable tool of thought to help you understand your problem, yes, but it is just one more tool in the toolbox For me those two sentences contradict each others. Types force you to draw an outline of your solution. For any non trivial problem this will be a time saver even in the prototype phase.

tmcb 7y ago
I can't see how they do, sorry. In fact, they complement each other. The usual static typing mechanisms I mentioned force you to approach a problem with their specific mindset, very much like math problems that add unreasonable constraints to their statements in order to check if you grasped a specific concept really well. In a real world scenario you should be able to reason your way out of the problem without such artificial constraints. So it should not be a restriction to anybody if they can accurately explain a concept or implement a program without using tools such as types.

lidHanteyk 7y ago

Static typing isn't bad, but it's only as good as the type system is strong and detailed. Haskell's QuickCheck doesn't understand biases or infinite-typed values. The Hypothesis strategy of Strategies (the design pattern) is far more useful for producing serious test suites, as less time has to be spent fretting about which invariants can be hoisted to the type system.

j88439h84 7y ago

Monkeytype generates type hints from runtime observation.

zozbot234 7y ago

> use both a completely untyped dynamic language such as Tcl, where everything is a string, and a static, strongly typed programming language (ideally a proof assistant with dependent types). This is gradual typing. The real problem with gradual typing is that you largely forgo the performance advantages of static typing, since you spend a lot of compute time translating data in and out of "dynamically-typed" (i.e. tagged/runtime dispatched) representations. This is especially obvious in stringly-typed languages ala Tcl, but applies elsewhere as well.

tmcb 7y ago
I don’t think so. My hopes here are that, in having two orthogonal code bases in extremely different languages, there would be no chance that typed and untyped code intertwine, hence compromising typing accuracy. I regard this possibility as a serious problem with gradually typed languages, one of those that risk to be addressed with lengthy software engineering books, those to be mentioned as mandatory knowledge on every single programmer job interview by the year of 2039. But I digress. “Abrupt typing” would describe this approach more precisely, if there was such jargon. A program module has no types while it is a prototype, but it must be completely typed (which is just another term for “having its correctness proved with the best tools available at this day and age”) before it goes into production.