Type Wars
blog.cleancoder.com
Type Wars
1–10 of 62 posts
Re: Type Wars
#2It's disappointing to see this post makes no mention of any ML style functional language or even Rust. It's hard to take a post with this kind of title (and predictions) seriously when it doesn't even mention the big (relatively) new players in the "Type Wars".
Re: Type Wars
#3> Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?
Couldn't you invert the question for Java and instead ask, why am I wasting my time chasing 100% test coverage when the type constraints of the language guarantee a certain degree of correctness?
I've always found that dynamic language projects require twice as many tests as a Java project to get a similarly reliable test suite.
Re: Type Wars
#4I don't know about what the author's goals are, but I am in favor of offloading as much work to computer as possible.
To err is to be human, but compilers never forget.
Re: Type Wars
#5> Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything? Couldn't you invert the question for Java and instead ask, why am I wasting my time chasing 100% test coverage when the type constraints of the language guarantee a certain degree of correctness? I've always found that dynamic language projects require twice as many tests as a Java project to get a simi…
I whole heartedly agree with this sentimate
Re: Type Wars
#6>The pendulum is quickly swinging towards dynamic typing. Programmers are leaving the statically typed languages like C++, Java, and C# in favor of the dynamically typed languages like Ruby and Python.
Even though this article is recent, it reads like it's a good several years out of date. From where I sit, Ruby and Python are incumbents and the trend is moving toward typed languages of several varieties. From ML variants to Scala to the "streamlined functional-ish" languages like Swift, Kotlin, whatever C# is morphing into, to Typescript, and so on.
He presents TDD as a convenient way to escape the shackles of static-typing. I think many, myself included, would regard compiler-enforced type safety as a way to leverage a machine to ease the significant burden of writing and maintaining a huge test suite. Not to mention the productivity boost provided by the comparatively richer tooling that static typing enables.
Re: Type Wars
#7>The pendulum is quickly swinging towards dynamic typing. Programmers are leaving the statically typed languages like C++, Java, and C# in favor of the dynamically typed languages like Ruby and Python. And yet, the new languages that are appearing, languages like go and swift appear to be reasserting static typing?
The author makes the claim that the pendulum is swinging back towards dynamic typing but then follows up immediately with the contradictory evidence that the new hip languages showing up are strongly typed.
I'm curious what if any evidence can be presented that this pendulum is swinging in any direction as oppose to just pulling at opposite ends as it has been for quite some time.
Re: Type Wars
#8> Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything? Couldn't you invert the question for Java and instead ask, why am I wasting my time chasing 100% test coverage when the type constraints of the language guarantee a certain degree of correctness? I've always found that dynamic language projects require twice as many tests as a Java project to get a simi…
This reminds me of a talk from StrangeLoop 2012 by Paul Snively and Amanda Laucher "Types vs Tests". Well worth the watch.
Re: Type Wars
#9Without those pesky types, how does one do automated refactoring in a large codebase? By hand?
Types are one of the hallmarks of large scale engineering. Any codebase of appreciable size without types is difficult to work in, at least in my own experience.
It takes a little bit more effort writing the types, but doing so saves so much time in the long run that it's absolutely worth it.
Re: Type Wars
#10I don't know about what the author's goals are, but I am in favor of offloading as much work to computer as possible. To err is to be human, but compilers never forget.
Good point, the author clearly misses the point that tests themselves are code and thus can have errors in them as well. Code coverage is just a vanity metric if you're tests don't actually test the correct thing.