Type Safety Doesn’t Matter

https://www.fpcomplete.com/blog/type-safety-doesnt-matter/

by zeroonetwothree • 2 years ago

9 14 2 years ago

fpcomplete.com

gnabgib• 2 years ago

Discussion [0] (20 points, 28 days ago, 24 comments)

[0] https://news.ycombinator.com/item?id=40165904

pavel_lishin• 2 years ago

The biggest use of types, for me, is being able to read code more easily. Right now, I'm elbow deep in some old PHP code, and it is painful trying to trace the flow of data through a system.

What is $item? What does it contain? I have no idea, and to find out, I have to dig through at least five files (so far) to figure out how it's put together.

green_dee• 2 years ago

nothing is better than vanilla javascript "props" object with no documentation, several non-consistent key calls and spaghetti code.

dimitrisnl2• 2 years ago

and some `...rest` spread that could be anything anytime in the future.

spankalee• 2 years ago

Came here to say basically the same thing. Reducing runtime errors is not the only benefit of types, or sometimes investing in complex types.

Ease of reading, code navigation, refactoring, producing documentation, code generation, etc... there are myriad benefits.

As you would expect from something that fundamentally helps computers (and humans) understand and verify the intent and structure of code better.

dimitrisnl2• 2 years ago

Good luck working with some nested structures.

Edit: I'm a bit triggered. I don't get how this trivial example showcases anything. You always use types. They are either written down or in your mind. Unfortunately, collaboration happens, and I'm not in your mind.

stnmtn• 2 years ago

I understand how you feel, I can't possibly imagine a scenario where you don't want to document types unless you're working on a project that you expect to not work on ever again in a month

willio58• 2 years ago

Is the time you’re spending on implementing the type-safe solution paying off in bug reduction and other benefits?

As someone working on a team with a large monorepo with strict type requirements, I will say my life is a lot easier with types than without. Types are documentation plain and simple, they require devs to state their intentions in code which is extremely valuable for other devs on the project.

LorenPechtel• 2 years ago

Yup. The more detail you can put in the code itself the better.

xigoi• 2 years ago

More importantly, they’re documentation which is guaranteed to be correct.

franky47• 2 years ago

The React example given at the end misses out on one issue where even linters can't help: fetching data and accessing its contents. Setting aside error handling (fetch call fails), the response data could have a different schema than what the code expects.

This is what parsers are for (in TS: zod, valibot, joi, yup et al). Preferably those that can express type definitions for their output that matches the runtime validation.

You can't have type-safety without untrusted input parsing.

tengbretson• 2 years ago

The funny thing is that this example would be much better with a type system that properly modeled state and effects.

000ooo000• 2 years ago

What I mean is that, on its own, type safety is not important. It’s only useful because of what it accomplishes: moving errors from runtime to compile time.

Air doesn't matter! It's only useful because of what our bodies do with it

hakunin• 2 years ago

I think not getting hung up on a method to solving a problem is a great message to remember. You should be open to switch to a different method if it solves the problem better.

Type safety is just one such method. The actual problem is making code easier to maintain for humans. Type safety is not always the best means to that end. Our brains perceive information in a complicated way. Sometimes too much information can overwhelm us and obfuscate something simple. Sometimes too much detail about each value can make us lose the overall flow of the program.

My advice: (aside from reading other people's code) try to read what you wrote, and have others read what you wrote in code reviews. Do you and your colleagues understand it? Make it as brief and simple as possible without losing that understanding. Address any "how" questions by rewriting the code clearer, "what" questions by improving naming, and "why" questions by adding comments. These are your code's 3 primary objectives: explaining how, what, and why to your colleagues. I once wrote a post about it.[1]

[1] https://max.engineer/maintainable-code

Type Safety Doesn’t Matter

Related Stories