Live data from Hacker News

Diminishing returns of static typing

blog.merovius.de

41–50 of 632 posts

Re: Diminishing returns of static typing

#41
post #35
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…

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.

Re: Diminishing returns of static typing

#42
post #31
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…

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.

If you believe there are no diminishing returns, I'm interested to hear your reply to the author's question about why we don't all use Agda or Idris.

Re: Diminishing returns of static typing

#43
post #13
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…

IMO the autocomplete argument is rather unconvincing. Every dynamic language I've worked deeply with has powerful and simple introspection capabilities, and they generally come with much more interactive development environments (shell/REPL), so I've never found API discoverability to be any worse than statically typed languages, just different. In general though, the more you can formally reason about the program, t…

The thing about magical refactoring though is that it often isn't a good idea. You usually don't just change the name of something, but you change it conceptually. If you just let the ide go and change the name everywhere, you create bugs because you never actually went and made sure the old code was updated for the new concept, rather than just the name.

Re: Diminishing returns of static typing

#44
post #13

Earlier quoted context omitted.

IMO the autocomplete argument is rather unconvincing. Every dynamic language I've worked deeply with has powerful and simple introspection capabilities, and they generally come with much more interactive development environments (shell/REPL), so I've never found API discoverability to be any worse than statically typed languages, just different. In general though, the more you can formally reason about the program, t…

Does anyone believe in using the wrong tool for the job?

At a place I worked at once, it was "use Microsoft for everything". So yeah.

Re: Diminishing returns of static typing

#45
The effort to fix a defect is proportional to the time between introduction of a defect and it's discovery.

This is a basic intuition behind all good practices, including CI, QA, etc.

Types allow one to discover program defects (even generalized ones, when using some of the programming languages) in (almost) shortest possible amount of time.

Types also allows one to constrain effects of various kind (again, use good language for this), which constraintment can make code simpler, safer and, in the end, more performant.

Re: Diminishing returns of static typing

#46
post #31
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…

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.

Re: Diminishing returns of static typing

#47
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…

If Visual Studio is your example, then you're making the same argument as the author: there's a sweet spot. From the python world, c# may look statically typed, but from the Haskell/Idris point of view, the java/c# type systems look really sloppy and ambiguous.

Re: Diminishing returns of static typing

#48
In this thread: people will bring out the same tired arguments for or against static typing, without commenting on the actual content of the post, which was quite good!

I have come to see type systems, like many pieces of computer science, can either be viewed as a math/research problem (in which generally more types = better) or as an engineering challenge, in which you're more concerned with understanding and balancing tradeoffs (bugs / velocity / ease of use / etc., as described in the post). These two mindsets are at odds and generally talk past each other because they don't fundamentally agree on which values are more important (like the great startups vs NASA example at the end).

Re: Diminishing returns of static typing

#49
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.

>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.

Re: Diminishing returns of static typing

#50
post #38
post #9

Earlier quoted context omitted.

Dynamic languages support this kind of tooling too - you can even have seamless data completion (eg. map/dictionary keys). The original Refactoring Browser was written for Smalltalk. Etc. Of course there are cases where dynamic languages do worse, but it balances out I think.

But how can you offer any refactoring or auto-complete inside a function if you don't know what type to expect as an argument?

In dynamic languages functions aren't typically overloaded by argument type.

For OO languages and methods it does get a little guesswork-y, and tools often offer a wider range of guesses than is correct for completion. But you can show the class along with the offered completion, so it's not too bad.

Post reply on HN