Live data from Hacker News

Type Wars

blog.cleancoder.com

31–40 of 62 posts

Re: Type Wars

#31

Honestly, I feel like the current is going the opposite direction here. In the mid-to-late 2000s the most ascendent languages seemed to be dynamic ones. Ruby, Python, PHP, Javascript, etc. Perhaps that's web solipsism, but those are the languages I remember having the highest visibility from that time. Currently, the tide seems to be changing to towards static typing (and stronger typing). Swift, rust, go, scala, etc…

A countercurrent is the rise of data science, machine learning and statistical programming in industry. Dynamic languages such as R and Python are the tools of that trade, because of the exploratory nature of the programming work that leads to an emphasis on speed and flexibility over correctness, and the loosely typed nature of datasets in the wild.

Re: Type Wars

#33
post #12

> The language is very opinionated about type safety... For example, the fact that a variable of type X might also be nil means you must declare that variable to hold an "optional" value... The extreme nature of the type system in swift Oh boy, if he thinks that's extreme... > Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything? Oh really? Are the unit test…

> Are the unit tests testing every single 2^64 possible values of an Int? Hmm...your usual type checker is checking 0 possible values of an int. It is checking just the type. And of course if you are checking a value in a test, you ar coincidentally also checking its type. That's not to say that types can't be useful (for example they have been shown to be quite useful as machine-checked documentation for getting aro…

The compiler can use the known bounds of a type to perform correctness checks or optimizations. It might not be testing every possible value of an int explicitly, but the compiler certainly uses the range of an int to make lots of decisions and produce warnings/errors.

Re: Type Wars

#34
> "Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything"

Not only is this a straw man, it's also a really weak argument.

Types prove the absence of (type) bugs. Tests can merely prove the presence of such bugs.

Re: Type Wars

#35
post #31

Honestly, I feel like the current is going the opposite direction here. In the mid-to-late 2000s the most ascendent languages seemed to be dynamic ones. Ruby, Python, PHP, Javascript, etc. Perhaps that's web solipsism, but those are the languages I remember having the highest visibility from that time. Currently, the tide seems to be changing to towards static typing (and stronger typing). Swift, rust, go, scala, etc…

A countercurrent is the rise of data science, machine learning and statistical programming in industry. Dynamic languages such as R and Python are the tools of that trade, because of the exploratory nature of the programming work that leads to an emphasis on speed and flexibility over correctness, and the loosely typed nature of datasets in the wild.

Julia has the best of both with the Any type. You can write Dynamic code and then tighten it up when you've got your system worked out.

Re: Type Wars

#36

Earlier quoted context omitted.

Exactly. Types are a class of tests, checked by the compiler at compile time.

Right. They are one class of tests that happens to be checked at compile time. But what about all the other tests that you still have to do? Which typically also coincidentally check the types (if I check that a value is > 2, I am also checking that its type is number (or int or whatever your particular numeric tower or non-tower says). And what is the value of "compile time", if the all this type checking makes the…

Don't underestimate the productivity boost provided by the little squiggly red line. The fact that your tooling will stop you from ever passing T when the expected parameter is Collection, and that this "rescue" involves pretty much zero cognitive overhead, is invaluable. When I work in a statically typed language, I find that I pretty much never make "head-desk" type errors, and despair at their reappearance when writing... javascript.

Re: Type Wars

#38
post #31

Honestly, I feel like the current is going the opposite direction here. In the mid-to-late 2000s the most ascendent languages seemed to be dynamic ones. Ruby, Python, PHP, Javascript, etc. Perhaps that's web solipsism, but those are the languages I remember having the highest visibility from that time. Currently, the tide seems to be changing to towards static typing (and stronger typing). Swift, rust, go, scala, etc…

A countercurrent is the rise of data science, machine learning and statistical programming in industry. Dynamic languages such as R and Python are the tools of that trade, because of the exploratory nature of the programming work that leads to an emphasis on speed and flexibility over correctness, and the loosely typed nature of datasets in the wild.

Good point, though I wouldn't say any of those languages represent new developments (Julia would be a good counterexample though). My understanding is that many of the new probabilistic programming languages are statically typed (hakaru, figaro, BLOG, etc.), though I'm not an expert in this field so I can't speculate on if that represents a coming tide change or not.

Re: Type Wars

#39

Earlier quoted context omitted.

"Clever" or "overly specialized", depending on your viewpoint.

Agreed, but I will say it's been a boon to my iOS development.

And to my Scala development :)

https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...

Post reply on HN