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

151–160 of 632 posts

Re: Diminishing returns of static typing

#151

Post by icebraining »

Eire_Banshee wrote: post #41
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.

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.

Re: Diminishing returns of static typing

#152

Post by matharmin »

19873287234 wrote: post #46
drblast wrote: post #31

Earlier quoted context omitted.

Definitely. Static typing lets you turn the compiler into a hard-working friend that helps you refactor large projects without going insane. There are no diminishing returns. Defining types is easy and enhances code readability.

I really don't think it does that. Most refactoring is not like that. It is about changing things at a deeper level than just the type. I don't think they enhance code readability - I think they make it worse. I never look at the type when I am reading code, it just gets in the way.

Semi-automatic refactoring tools is just one part of what a type system enables. A much bigger benefit in my opinion is that it immediately highlights issues in your code while you are refactoring. Basically answer "What do I still need to change to finish the refactoring?". Unit testing also gives you some of this, but is typically much slower - both in execution time, and the additional time it takes to figure out where the issue is.

Re: Diminishing returns of static typing

#153

Post by icebraining »

201709User wrote: post #147
enraged_camel wrote: post #143

Earlier quoted context omitted.

>>There are a class of bugs you just never need to worry about when the compiler does some compile-time checks for you ... like worrying that you passed the wrong type into a function, or the wrong number of arguments. People always say this and it baffles me. Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you.

Yes, why do something automatically when you can do manual work!

I think the idea is that you have to write tests anyway.

Re: Diminishing returns of static typing

#154

Post by fulafel »

gwbas1c wrote: post #113
cm2187 wrote: post #3

The benefit of static typing isn't just reliability. Tooling is another major argument. Won't appeal to certain hardcore programmers who think that even notepad has too many features. But it is great for refactoring, finding all references to a function or a property or navigating through the code at design time. Basically all the features visual studio excels at for .net languages. And I disagree with the barrier to…

Isn't static typing a requirement when writing an algorithm and data structures for "every bit and clock cycle counts" situations? How can a 0-compute overhead for dynamic typing exist in a dynamic typed environment? I always thought dynamic typing is a feature for situations where the code needs an extreme amount of flexibility to adapt to a wide variety of data; even at the expense of performance.

Advanced compilation techniques can transform (input data, input program) into a statically typed program, so the at the limit the answer is strictly "no". See partial evaluation, futamura projections, etc- or JS JITs for more down to earth stuff (though sidestepping data transformations).

Re: Diminishing returns of static typing

#155

Post by andrewaylett »

enraged_camel wrote: post #143
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,…

>>There are a class of bugs you just never need to worry about when the compiler does some compile-time checks for you ... like worrying that you passed the wrong type into a function, or the wrong number of arguments. People always say this and it baffles me. Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you.

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.

Re: Diminishing returns of static typing

#156

Post by flavio81 »

Eire_Banshee wrote: post #56
flavio81 wrote: post #49

Earlier quoted context omitted.

>Not just, "who the hell uses this", but "where the hell is this defined" as well. On Common Lisp, a dynamic language, I can also get this answered instantly. I just press a key combination on a method call and i jump to the definition. So this isn't exclusive to statically typed languages.

Lets be real, when we say dynamic languages, we aren't talking about niche languages like Lisp. We are talking about JS and Python almost exclusively.

>Lets be real, when we say dynamic languages, we aren't talking about niche languages like Lisp.

How can it be a niche language, if it's an ANSI standard, has more than 8 or 10 fully feature, standard-conformant implementations, runs on most CPU types, and has been proven to work in production systems for spaceship guiding, worldwide airfare reservation and credit card transaction verification?

You use Js and Python because you choose to use it, but it's not the only choice. Not only Common Lisp, you could also be working in Clojure with many benefits.

Re: Diminishing returns of static typing

#157

Post by KingMob »

igouy wrote: post #67
gnaritas wrote: post #33

Earlier quoted context omitted.

I can do all of those things in Smalltalk, which is dynamically typed; these things are not byproducts of static typing, they're simply byproducts of mature tools. So no, these are not arguments in favor of static types.

>> finding all references to a function Yes, you can find all references to a method in Smalltalk -- but those references are not separated-out from all the references to other methods that happen to have the same method name but are defined on a different class. With type information for the receiver and method arguments, we can find just the references we're looking for.

I can't speak to Smalltalk, but any namespaced Lisp system can figure out what references what. The key is that the searches happen through the REPL, not grep/ag. So if I tell CIDER to find all instances of a Clojure symbol, it can use the namespace to avoid false positives.

Re: Diminishing returns of static typing

#158

Post by mpartel »

willtim wrote: post #115
mpartel wrote: post #74

Earlier quoted context omitted.

I am. I think the OP is fundamentally right about the sweet spot being pretty far from either extreme, I just disagree slightly about where exactly :) Subjectively, I use ordinary generics all the time, but see the need for HKTs only occasionally. It's entirely possible I'm not experienced enough to see most of their possible use cases, but then I'd wager most programmers aren't.

In retrospect, HKTs are arguably Haskells greatest innovation, enabling extremely general abstractions and huge amounts of code reuse.

In my subjective opinion, Haskell has taken abstraction way past the point of diminishing returns, at least for the problems I tend to work on.

A large portion of advanced Haskell type system features seem to be about emulating things you could do with side-effects. I guess I prefer Rust's approach to managing side-effects, or even just Scala's implied convention of: use 'var' very sparingly, and mostly locally. Yes, some guarantees get traded away, but so much simplicity is gained.

I'm not very experienced with Haskell, but I've written a fair bit of Scala and I've utterly failed to see the value in scalaz and similar libraries, despite trying them a few times. They always seem to add lots of complexity without a tangible benefit.

Coming at it from another angle, I just don't see many cases where I feel I have to repeat myself due to a shortcoming of, say, Java's or C#'s type system. If I could add one feature to either, it'd actually be support for variadic type parameters.

Re: Diminishing returns of static typing

#159

Post by bjz_ »

lopatin wrote: post #89
namelost wrote: post #40

Earlier quoted context omitted.

Yeah far from finding a sweet spot, Go exists in some kind of type system ghetto, because its type system is so crippled users have to resort to code generation (go generate). Neither Python nor Java programmers have to do that.

Yeah Go is weird in that its static type system doesn't to provide you with great static typing power but instead it's just there as a sort-of sanity checker. If there's logic, they say write it with data structures and functions. Have invariants? Enforce them yourself. If Go is annoying with how little power it provides, that's fair, but other type systems can be just as annoying then, because when given the ability…

Yeah, I've noticed that Go APIs are very stringly typed. The APIs are not very self documenting, and it is hard to figure out whether something is nullable or not. Libraries often require you to initialised data in a partially invalid state and the whole thing feels quite error-prone and flaky.

Re: Diminishing returns of static typing

#160

Post by tom_mellior »

hwayne wrote: post #110
tom_mellior wrote: post #66

Earlier quoted context omitted.

> The asymptote cannot reach 100% of program behavior in any finitary way. That would solve the halting problem. There are languages that enforce termination. They only accept programs that can be shown to terminate through syntactic reasoning (e.g., when processing lists, you only recurse on the tail), or where you can prove termination by other means. Coq is like this, as is Isabelle, as is F* , as are others. They…

> This "we can never be sure of anything, because the halting problem" meme is getting boring. Yes, you cannot write the Collatz function in Coq. No, that is not a limitation in the real world. How about, say, a video game? That's something where we reasonably _want_ it to not terminate, because we're primarily interested in its side effects.

That's what the escape hatches are for. In Coq, for instance, you can also write functions processing infinite streams, provided that they also produce something regularly. For example, in a game, you could write a function from an infinite stream of inputs to an infinite stream of frame updates. You can not write functions that would not terminate while computing the updates for some given frame.

Alternatively, you just write a function to iterate your game world update N times, where you choose N large enough to ensure that your game can run until the heat death of the universe. That's not a nonterminating function, but it's long-running enough for all practical purposes.

Post reply on HN