Diminishing returns of static typing • Hacker News Board

Re: Diminishing returns of static typing

#21

Post by wootness » Mon, Oct 02, 2017, 3:43 PM UTC

cle wrote: post #13

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…

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…

I found Ruby (even in something like RubyMine) to be a far cry from even the basic stuff you get from Java. Suggestions for vars and funcs that don't actually exist really slowed down things.

Re: Diminishing returns of static typing

#22

Post by ruskimalooski » Mon, Oct 02, 2017, 3:43 PM UTC

gipp wrote: post #19

ruskimalooski wrote: post #14

These graphs really mean nothing. There is no data behind them. I might as well make a graph that conveys a non-descript correlation between how much an article bashes static typing & assertion and how high it is on HN.

They're just sketches. That's part of the point, and the article says that directly. The point isn't the exact shape or slope of the curves, but just their asymptotic behavior and the relationship of "correct features/day" to the other two. I.e. As long as the two curves have that general shape, then the "sweet spot" exists somewhere between 0-100%, the exact location of which depends on language, developer experienc…

But even the asymptotes are an assumption derived from pure thought experiment.

Re: Diminishing returns of static typing

#23

Post by emodendroket » Mon, Oct 02, 2017, 3:44 PM UTC

cle wrote: post #13

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…

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?

Re: Diminishing returns of static typing

#24

Post by _Codemonkeyism » Mon, Oct 02, 2017, 3:45 PM UTC

I like for example Refined

https://github.com/fthomas/refined

not only for the static checking,

    scala> val i: Int Refined Positive = -5
    :22: error: Predicate failed: (-5 > 0).
            val i: Int Refined Positive = -5

but the expressive descriptions of a domain model.

Re: Diminishing returns of static typing

#25

Post by msla » Mon, Oct 02, 2017, 3:46 PM UTC

cle wrote: post #13

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…

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…

Yeah, I agree: Two of the languages with the best autocomplete and introspection in general are Common Lisp and Smalltalk. Some of that's simple maturity, but it proves that those features can work very, very well in even the most dynamic languages around.

Re: Diminishing returns of static typing

#26

Post by brango » Mon, Oct 02, 2017, 3:48 PM UTC

Why my favorite color is red not blue...

Re: Diminishing returns of static typing

#27

Post by GenericsMotors » Mon, Oct 02, 2017, 3:48 PM UTC

stephengillie wrote: post #4

One of my favorite parts of Powershell is optional typing. Variables are a generic "Object" type by default, which can hold anything from a string to array to "Amazon.AWS.Model.EC2.Tag" or other custom types. Or, type can be specified when setting the variable: [String]$myString = "Hello World!" This would generate a type error: [Int]$myString = "Hello World!" Often, typed and untyped variables will sit together: [In…

Indeed! I think one of my favourites has to be:

    [xml]$someXmlDocument = Get-Content "path\to\file.xml"

And you get a deserialized version of the XML text.

Also the fact that you can use types when declaring function arguments, removing the need to manually test if an object of the desired type was passed.

Powershell definitely strikes a good balance on type safety for a scripting language.

Re: Diminishing returns of static typing

#28

Post by danharaj » Mon, Oct 02, 2017, 3:48 PM UTC

agentultra wrote: post #10

I think what's often missing from these arguments is that statically checking (or inferring) homogenous lists is probably one of the most superficial uses of the type system in Haskell (and indeed not the interesting feature most power-users of Haskell are interested in as far as I can tell). What is interesting is using the type system to specify invariants about data structures and functions at the type level befor…

List typing isn't as superficial as it seems. The following has happened to me multiple times, perhaps in the last month:

I have a large code base. I want to replace a fundamental data structure to support more operations/invariants/performance guarantees. I change the type at the roots of the code base. My instance of ghcid notifies me of the first type error. I fix it. This repeats until the program compiles again. I run the tests. All the tests pass.

This is insane in Python/C/Ruby. I've had to do it in C and Python. In Haskell I do it with impunity.

The type system doesn't just check what my program does, it is the compass, map, and hiking gear that gets me through the wilderness.

Re: Diminishing returns of static typing

#29

Post by christopheml » Mon, Oct 02, 2017, 3:48 PM UTC

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…

My main progamming language at the time is Java, and the amount of assistance my IDE provides is astonishing (to the surprise of no one, it's IntelliJ). The confidence strong automatic refactors provide is of great help when managing large codebases.

Re: Diminishing returns of static typing

#30

Post by disconnected » Mon, Oct 02, 2017, 3:49 PM UTC

emodendroket wrote: post #23

cle wrote: 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?

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

Yes. PHP developers.

:)