Why Type Systems Matter
matthias-endler.de
Why Type Systems Matter
1–10 of 103 posts
Re: Why Type Systems Matter
#2Strong typing is great when I've already made sense of how the logic should flow and I'm ready to solidify my work into something stable and extensible over time. It's not so great when I'm trying something new and am still trying to work out if what I want to do is even possible, since I find myself trying to identify the right type to use in a given situation rather than proving that I'm even able to do it. A lot of my daily work is prototyping.
Re: Why Type Systems Matter
#3Good post, but note all those things you don't need a statically typed language. Erlang for example is a dynamically typed language but it has Dialyzer - a type checker. The more precisely you define the types the more discrepancies and issues it will find in the code, exactly the kind of stuff the author mentions.
http://learnyousomeerlang.com/dialyzer
That's technically called "success typing" http://www.it.uu.se/research/group/hipe/papers/succ_types.pd...
Python has that too with MyPy. That came much later than Erlang and I haven't used yet so not sure how well it works
They seemed to have copied success typing but don't actually mention it anywhere.
Re: Why Type Systems Matter
#4Strong typing is great when I've already made sense of how the logic should flow and I'm ready to solidify my work into something stable and extensible over time. It's not so great when I'm trying something new and am still trying to work out if what I want to do is even possible, since I find myself trying to identify the right type to use in a given situation rather than proving that I'm even able to do it. A lot o…
There's no reason why static type errors can't be deferred until runtime, GHC Haskell can do this. Personally I find types invaluable when prototyping. I often fill in the implementations after I work out the types.
Re: Why Type Systems Matter
#5Strong typing is great when I've already made sense of how the logic should flow and I'm ready to solidify my work into something stable and extensible over time. It's not so great when I'm trying something new and am still trying to work out if what I want to do is even possible, since I find myself trying to identify the right type to use in a given situation rather than proving that I'm even able to do it. A lot o…
> Strong typing
I think you mean 'static' typing, not strong? Python is already strongly typed.
> It's not so great when I'm trying something new and am still trying to work out if what I want to do is even possible
I completely agree here. I find it very useful when iterating to run the program and verify just the code path that gets executed, without worrying about whether the rest of the program is also correctly typed. Once I have settled on a set of types though, it would be nice if Python told me all the places that now need to be fixed up.
Re: Why Type Systems Matter
#6Strong typing is great when I've already made sense of how the logic should flow and I'm ready to solidify my work into something stable and extensible over time. It's not so great when I'm trying something new and am still trying to work out if what I want to do is even possible, since I find myself trying to identify the right type to use in a given situation rather than proving that I'm even able to do it. A lot o…
There's no reason why static type errors can't be deferred until runtime, GHC Haskell can do this. Personally I find types invaluable when prototyping. I often fill in the implementations after I work out the types.
I wish this was adopted more broadly, e.g. by Rust and other newer languages.
Re: Why Type Systems Matter
#7Earlier quoted context omitted.
There's no reason why static type errors can't be deferred until runtime, GHC Haskell can do this. Personally I find types invaluable when prototyping. I often fill in the implementations after I work out the types.
I wish this was adopted more broadly, e.g. by Rust and other newer languages.
What would the semantics of that be? Something like "this function contains a type error, so if you call it your code will just panic?"
Re: Why Type Systems Matter
#8A line from a novel by Georgette Heyer: "I look for trouble. I don't wait to have it brought to my attention."
That is, if there's a type problem, I want to know at compile time, not at run time.
But I'm in embedded systems. My stuff looks like just a machine to the customer. They don't want a type error at runtime messing them up. That may not be your world. If you'd rather things go happily along until the circumstances actually occur in execution, and if that ever happens, you then find out about the type problem, well, that's what is reasonable to you in your environment and circumstances, and that's fine. Use dynamic typing, and don't feel guilty.
Re: Why Type Systems Matter
#9Earlier quoted context omitted.
I wish this was adopted more broadly, e.g. by Rust and other newer languages.
What would the semantics of that be? Something like "this function contains a type error, so if you call it your code will just panic?"
At it's simplest, I could see it being a compiler flag. No annotations needed. Default would be strict compile-time typing. But with a flag, you could turn type errors into warnings (and runtime panics), or even into not-even-warnings, just silence (and runtime panics).
Re: Why Type Systems Matter
#10Earlier quoted context omitted.
I wish this was adopted more broadly, e.g. by Rust and other newer languages.
What would the semantics of that be? Something like "this function contains a type error, so if you call it your code will just panic?"
Haskell can defer them by producing thunks (values) containing runtime exceptions. But unlike a dynamic-only language, you still get to know about the errors at compile time, by way of a set of warnings.