3 ms·
I haven't yet seen the typing light, so maybe my perspective might spawn some replies that could help. I understand that types are helpful, especially within t
by drusepth 5y ago
I haven't yet seen the typing light, so maybe my perspective might spawn some replies that could help.
I understand that types are helpful, especially within the context of learning new code (both as a new dev, and more easily understanding new code written by your team), but my hesitation to "jump ship" to them comes from weighing all the "boilerplate" code necessary to get them working versus the tangible benefits I feel they'd give.
To that end, maybe enumerating over the benefits for your friends (ideally more specifically than just "fewer bugs" or "easier to read/write") might tilt the scale more towards using them.
The article shows some good examples of problems that types solve, but many of them could also be "fixed" with better naming schemes, standardizations, and/or refactors -- and then wouldn't also be littered with type annotations (which take up 50% of the code in their example, [1], where I've also added a couple other easy-to-understand "solutions" with less cruft.
IMO, most of the typing syntax in their examples is distracting from the actual code -- especially when just writing better or more standardized code (which you still need to do with types) would make the typing syntax, again IMO, less necessary.
[1] https://sorbet.run/#%23%20typed%3A%20true%0Aextend%20T%3A%3ASig%0A%0Aclass%20Invoice%0A%20%20%23%20...%0Aend%0A%0Asig%20%7Bparams%28invoice%3A%20Invoice%2C%20paid%3A%20T%3A%3ABoolean%29.void%7D%0Adef%20update_invoice%28invoice%2C%20paid%29%0A%20%20%23%20...%0Aend%0A%0A%23%20error%3A%20Expected%20%60Invoice%60%20but%20found%20%60String%60%20for%20argument%20%60invoice%60%0Aupdate_invoice%28'in_1KZ7eP2eZvKYlo2C3B98SLc9'%2C%20true%29%0A%0A%0A%0A%0A%0A%0A%0Aclass%20Invoice%0A%20%20%23%20...%0Aend%0A%0Adef%20update_invoice_paid%28invoice_id%2C%20paid%29%0A%20%20%23%20...%0Aend%0A%0Aupdate_invoice_paid%28'in_1KZ7eP2eZvKYlo2C3B98SLc9'%2C%20true%29%0A%0A%0A%0A%0A%0A%0A%0Aclass%20Invoice%0A%20%20%23%20...%0Aend%0A%0Adef%20update_invoice%28invoice_id%3A%2C%20paid%3A%29%0A%20%20%23%20...%0Aend%0A%0Aupdate_invoice%28invoice_id%3A%20'in_1KZ7eP2eZvKYlo2C3B98SLc9'%2C%20paid%3A%20true%29 https://sorbet.run/#%23%20typed%3A%20true%0Aextend%20T%3A%3A...
- hardwaresofton 5y agoYeah unfortunately this is one of the problems, bolting on the types rarely works as well as it does for Typescript (looks quite natural to me). In Haskell for example, writing signatures is actually both unnecessary (they will be inferrable, most of the time so it's basically only for humans to read) and a net positive (they fit well prose wise and you can use them as documentation) but that's a harder hill to climb. I do want to note that one big advantage of specifying signatures is that now your IDE can help you when using the functions and detect when something is going wrong. Maybe "no more trying to figure out what the input/output of a function that you didn't write is supposed to be" would be a draw?