{"id":16906,"date":"2017-01-12T15:31:19","date_gmt":"2017-01-12T20:31:19","guid":{"rendered":"http:\/\/mjtsai.com\/blog\/?p=16906"},"modified":"2019-02-14T10:43:04","modified_gmt":"2019-02-14T15:43:04","slug":"static-typing-vs-testing","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2017\/01\/12\/static-typing-vs-testing\/","title":{"rendered":"Static Typing vs. Testing"},"content":{"rendered":"

Robert C. Martin<\/a> (Reddit<\/a>):<\/p>\n

My problem is that both [Swift and Kotlin] have doubled down on strong static typing. Both seem to be intent on closing every single type hole<\/em> in their parent languages.<\/p>

[…]<\/p>

But before you run out of fingers and toes, you have created languages that contain dozens of keywords, hundreds of constraints, a tortuous syntax, and a reference manual that reads like a law book. Indeed, to become an expert in these languages, you must become a language lawyer<\/em> (a term that was invented during the C++ era.)<\/p>

[…]<\/p>

Why are these languages adopting all these features? Because programmers are not testing<\/em> their code. And because programmers are not testing their code, we now have languages that force<\/em> us to put the word open<\/code> in front of every class we want to derive from. We now have languages that force<\/em> us to adorn every function, all the way up the calling tree, with try!<\/code>. We now have languages that are so constraining, and so over-specified, that you have to design the whole system up front before you can code any of it.<\/p>\n

[…]<\/p>\n

All these constraints, that these languages are imposing, presume that the programmer has perfect knowledge of the system; before the system is written<\/em>.<\/p><\/blockquote>\n\n

Drew McCormack<\/a>:<\/p>\n

Not in total agreement with the post, but quite a lot of agreement.<\/p><\/blockquote>\n\n

Joe Groff<\/a>:<\/p>\n

A type system is only as static as the code it describes. If you can change code, you can change types! The machine can even help you.<\/p><\/blockquote>\n\n

Chris Eidhof<\/a>:<\/p>\n

I don’t think it’s an either\/or situation at all: we can have a solid type system and write “manual” tests.<\/p>\n

A type checker actually does testing for you. It’s not a replacement for TDD, but it allows you to completely get rid of a whole bunch of tests.<\/p>\n

[…]<\/p>\n

In Swift, once you change foo<\/code> to return an Int?<\/code>, the compiler will now show an error for each time you call foo<\/code>. This makes it easy<\/em> to make that change, because until you have reviewed every single call to foo<\/code>, the program simply won’t compile. I think of the compile errors as a todo-list, not as a speed bump<\/a>.<\/p><\/blockquote>\n\n

Krzysztof Zabłocki<\/a>:<\/p>\n

I’m pro testing but I think this matches my thoughts exactly, almost anything you can do to get errors earlier in dev process is worth it.<\/p><\/blockquote>\n\n

I like both testing and types. The problem is that sometimes types get in the way. It would be nice to be able to do some work in a more dynamic style and then nail things down before shipping. That is the promise of type inference, but it’s not the reality of developing in Swift today.<\/p>\n\n

Update (2017-01-12): Isaiah Carew<\/a>:<\/p>\n

i wish i could have both. static typing is really useful sometimes. really a burden other times.<\/p><\/blockquote>\n\n

David Owens II<\/a>:<\/p>\n

My main problem with Swift has always been this: far too pedantic about types and complete lack of a dynamic runtime.<\/p><\/blockquote>\n\n

Update (2017-01-13): Mark Bernstein<\/a>:<\/p>\n

Reading this debate, I was startled to realize one thing I’d overlooked: I almost never make type errors. I make plenty of errors – for me, programming is always about correcting errors – but type errors are once in a blue moon affairs.<\/p>\n

I wonder if strong typing is a solution to a problem we don’t really have, or whether I’m just Doing It Wrong.<\/p><\/blockquote>\n

I concur. I think Swift’s optionals solve a real problem. The stronger typing, e.g. for collections, can make calling APIs more concise and help with auto-completion, but I don’t see this preventing many errors for me.<\/p>\n\n

Update (2017-01-14): Robert C. Martin<\/a>:<\/p>\n

To be clear, and at the risk of being repetitive, that blog was not an indictment of static typing. I rather enjoy static typing. I’ve spent the last 30 years working in statically typed languages and have gotten rather used to them.<\/p>

My intent, with that blog, was to complain about how far the pendulum has swung. I consider the static typing of Swift and Kotlin to have swung too far in the statically type-checked direction. They have, IMHO, passed the point where the tradeoff between expressiveness and constraint is profitable.<\/p>

[…]<\/p>

You might therefore say that the type system is a kind of “test” that fails for all inappropriate invocations of f<\/code>. I might concede that point except for one thing – the way f<\/code> is called has nothing to do with the required behavior of the system<\/em>. Rather it is a test of an arbitrary constraint imposed by the programmer. A constraint that was likely over<\/em> specified from the point of view of the system requirements.<\/p>\n

[…]<\/p>\n

So what the type system is checking is not the external behavior of the program. It is checking only the internal consistency of the program text.<\/p><\/blockquote>","protected":false},"excerpt":{"rendered":"

Robert C. Martin (Reddit): My problem is that both [Swift and Kotlin] have doubled down on strong static typing. Both seem to be intent on closing every single type hole in their parent languages.[…]But before you run out of fingers and toes, you have created languages that contain dozens of keywords, hundreds of constraints, a […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"2019-02-14T15:43:06Z","apple_news_api_id":"4278e45c-cb57-42d9-b441-b0fc3449c109","apple_news_api_modified_at":"2019-02-14T15:43:07Z","apple_news_api_revision":"AAAAAAAAAAD\/\/\/\/\/\/\/\/\/\/w==","apple_news_api_share_url":"https:\/\/apple.news\/AQnjkXMtXQtm0QbD8NEnBCQ","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[4],"tags":[46,71,901,268],"class_list":["post-16906","post","type-post","status-publish","format-standard","hentry","category-programming-category","tag-languagedesign","tag-programming","tag-swift-programming-language","tag-testing"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/16906","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=16906"}],"version-history":[{"count":7,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/16906\/revisions"}],"predecessor-version":[{"id":24298,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/16906\/revisions\/24298"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=16906"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=16906"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=16906"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}