Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Diminishing returns of static typing

blog.merovius.de

Post reply on HN
Print view View original

231–240 of 632 posts

Re: Diminishing returns of static typing

#231

Post by macspoofing »

icebraining wrote: post #162
macspoofing wrote: post #60

Earlier quoted context omitted.

I'm so happy to see the pendulum swing the other way, because when JavaScript was becoming popular, and Ruby and Python had a popularity renaissance (around mid to late 2000s), I had a lot of online arguments about the value of static typing. People were complaining about static typing for the dumbest reasons (it's too 'wordy'). It started as a backlash against old-school enterprise Java development (which was fair,…

Typing in Java could be better, sure, but even with its quirks it's way better than the nothing you get with dynamic languages. I disagree; that Java was the standard example of statically typed languages is what convinced me for a long time that I didn't want anything to do with it. Having to pollute my code with all that crap, deal with a lot of dumb restrictions and still have NPEs left me with a sour taste. Only…

>Having to pollute my code with all that crap

What crap? Types?

>deal with a lot of dumb restrictions

Like what?

Re: Diminishing returns of static typing

#232

Post by Peaker »

icebraining wrote: post #151
Eire_Banshee wrote: post #41

Earlier quoted context omitted.

This. Not just, "who the hell uses this", but "where the hell is this defined" as well.

PyCharm gets it right 99% of the time. That 1% is hardly worth switching the a different language.

For someone paranoid about correctness, that's 1% of lingering doubt about every single operation in the IDE.

The 99% stat is quite likely a big exaggeration.

Refactoring is far far harder to do reliably, and more straining as so much more responsibility on the programmer.

Re: Diminishing returns of static typing

#233

Post by naasking »

tonyg wrote: post #230
naasking wrote: post #181

Earlier quoted context omitted.

Assembly is typed. The types are machine words and usually floating point types are also available. Basically, the machine types are the types of data that the register files can hold.

Yep. You can, of course, make a similar argument for Scheme. But you don't get a very interesting type system out of it. Perhaps I should have written "... nontrivially statically typed."

Sure, but to bring it back to the original question, the fact that you can trivially distinguish floating point from word types already means statically typed languages are easier to optimize than dynamically typed languages for numerical programs.

And there are all sorts of optimizations like this that simply aren't available to dynamically typed languages. Tracing JIT can only take you so far.

Re: Diminishing returns of static typing

#234

Post by macspoofing »

metaphorm wrote: post #177
andrewaylett wrote: post #155

Earlier quoted context omitted.

Why would I write test-cases for something the compiler can catch for me? Yes, I need to write tests for all the correctly-typed cases, but there are a whole class of bugs that I don't need to test for any more because I can't even write the failing case.

you're already writing the test cases to ensure correct behavior with typical input, and predictable exceptional input. putting in one more assert for predictable exceptional input (wrong type) doesn't really add a noticeable amount of overhead to writing the tests you were already writing.

>putting in one more assert for predictable exceptional input (wrong type) doesn't really add a noticeable amount of overhead

Yes. We call that 'typing'.

Re: Diminishing returns of static typing

#235

Post by emodendroket »

cle wrote: post #95
emodendroket wrote: post #62

Earlier quoted context omitted.

It might still, at least arguably, be "the right tool for the job." If you have a huge team of expert C# developers C# might be "the right tool for the job" even if it would be a little easier to do in a different language, given the same pool of experts in that language.

Agree. My point is that, if I personally dislike C# (I don't), and I'm on a team of C# experts and C# is the best choice for shipping the product given those experts and all the other use cases, then C# is the best tool for the job and I'll peruse C# documentation. I try my best to focus objectively on the product, not my ego or subjective preferences...and I often fail :(.

I've been writing PHP for a couple months and I've been pleasantly surprised so I feel like I am moving beyond that.

Re: Diminishing returns of static typing

#236

Post by whyever »

hellofunk wrote: post #210
continuational wrote: post #97

Earlier quoted context omitted.

Static typing reduces the time you spend on debugging. Automatically reducing errors in code is not just for reducing errors in the resulting program. It also greatly reduces the time you spend on hunting bugs, especially if you have a poorly designed type systems where errors are reported far from their origin. Null, interface{}, NaN etc. propagates errors and thus gives you a stacktrace that is worthless when it fi…

In my experience, the time saved from writing in a statically typed language where the compiler catches the bugs for you is made up by having to work more closely with the compiler, typically write more code (type annotations and other things) and in general spend that same time on compile-time rather than run-time bug hunting. Dynamically typed languages typically involve a lot less code, which is time gained. That…

The thing is that errors at compile time get reported almost instantly, but errors at runtime might be reported hours after you started your program if you are unlucky.

Re: Diminishing returns of static typing

#237

Post by tonyg »

naasking wrote: post #233
tonyg wrote: post #230

Earlier quoted context omitted.

Yep. You can, of course, make a similar argument for Scheme. But you don't get a very interesting type system out of it. Perhaps I should have written "... nontrivially statically typed."

Sure, but to bring it back to the original question, the fact that you can trivially distinguish floating point from word types already means statically typed languages are easier to optimize than dynamically typed languages for numerical programs. And there are all sorts of optimizations like this that simply aren't available to dynamically typed languages. Tracing JIT can only take you so far.

OK, but that wasn't the original question.

(There are also all sorts of optimizations that can't be done statically, so I guess there's that.)

Re: Diminishing returns of static typing

#238

Post by sly010 »

mozey wrote: post #77
Eridrus wrote: post #35

Earlier quoted context omitted.

I think dynamic typing proponents get hung up on the auto-complete aspect. The real benefit is when you find someone writing a property with a common-ish name to a data structure and you want to know "who the hell uses this", you can answer that question pretty easy in statically typed languages. In dynamically typed languages you kind of just grep and hope the name is not too common.

And "what the hell is this?" when you see a data structure called "options"

And "why? oh, why?" when that data structure is unvalidated json and the only way to enumerate all options is to read all the code

Re: Diminishing returns of static typing

#239

Post by hellofunk »

whyever wrote: post #236
hellofunk wrote: post #210

Earlier quoted context omitted.

In my experience, the time saved from writing in a statically typed language where the compiler catches the bugs for you is made up by having to work more closely with the compiler, typically write more code (type annotations and other things) and in general spend that same time on compile-time rather than run-time bug hunting. Dynamically typed languages typically involve a lot less code, which is time gained. That…

The thing is that errors at compile time get reported almost instantly, but errors at runtime might be reported hours after you started your program if you are unlucky.

That's entirely correct, and one of the tradeoffs.

However, in a statically-typed language, you must satisfy the type checker for everything, which adds development time. In reality, there might be a small percentage of functions in your code base for which errors (either compile-time or run-time) would likely crop up, yet you must pay that cost for 100% of them.

So that's really where the debate comes from.

Dynamically typed languages can get around this problem by generative testing (in Clojure's case) which allow very fine-tuned aspects of your system's requirements to be automatically tested before run-time without writing tests, which offers some of the same confidence as a compiler.

Re: Diminishing returns of static typing

#240

Post by bjz_ »

cm2187 wrote: post #222
bjz_ wrote: post #145

Earlier quoted context omitted.

Yes! If your language allows you to put constraints on those types you can specify what specific types have access to. For example in Rust: fn foo (x: &T) -> Point { x.position() } Note that this doesn't work in languages that use templates for generics, like C++, where templates work more like compile-time duck typing.

But, if I may, you are effectively statically typing your code.

Oh wait, I misread the comment you were responding to. Oops!
Post reply on HN