The Ergonomics of Type Checking (2016)

Re:The Ergonomics of Type Checking (2016) by z3t4 on Saturday October 28, 2017 @06:32PM (#15577019)

in JavaScript I pepper each function with if(...) throw, eg the program will throw if something is wrong. Doing this catches a lot of errors and bad state. - Without having to babysit a compiler (Typescript) and I can enjoy all the dynamic features. Sometimes I miss the type annotation as documentation, but then I just rename the variable to make it more clear what it is and does.

[ Parent | on HN ]

Re:The Ergonomics of Type Checking (2016) by bitwalker on Saturday October 28, 2017 @06:57PM (#15577112)

Instead of "babysitting" your compiler, you're "babysitting" your application at runtime - I fail to see the difference.

[ Parent | on HN ]

Re:The Ergonomics of Type Checking (2016) by z3t4 on Sunday October 29, 2017 @03:17AM (#15578315)

Good point. Think of it as hand-holding your peers instead of hand-holding the compiler. if(x==y) throw "friendly error" // avoids eternal loop ... The compiler doesn't care if you get an eternal loop at runtime, and static types wont prevent it.

[ Parent | on HN ]

Re:The Ergonomics of Type Checking (2016) by bitwalker on Sunday October 29, 2017 @03:13PM (#15580820)

What prevents you from writing the exact same exceptional code in a static system? I'm not sure I understand your point.

[ Parent | on HN ]

Re:The Ergonomics of Type Checking (2016) by z3t4 on Tuesday October 31, 2017 @10:09AM (#15593320)

If you make it a habit to write exceptions, it's more likely that you would. Some people think tests etc is only needed because the language is dynamic.

[ Parent | on HN ]