Diminishing returns of static typing • Hacker News Board

Re: Diminishing returns of static typing

#141

Post by catnaroek » Mon, Oct 02, 2017, 5:21 PM UTC

Arcsech wrote: post #78

ridiculous_fish wrote: post #42

Earlier quoted context omitted.

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.

Well, the easy answer is that dependently-typed languages like Agda and Idris aren't very mature yet. They're still missing many commonly-needed libraries, compile times are slow, the tooling isn't great, etc etc. Getting a language to the point where it's workable for serious projects is a lot of work. Rust is getting there with the backing of Mozilla, Haskell has made some decent strides too (but still has a way to…

It isn't just a matter of tooling. There exist hard limits on how much can be inferred about unannotated programs, and when you go past those limits, the price you have to pay is to embed (partial) proofs of correctness in your own code. For example, think about why GADTs don't play nicely with type inference.

IMO, machine assistance is useful to the extent it relieves us humans from work. In particular, types are useful to the extent they can be inferred. Beyond that, you still need to prove the correctness of your programs on your own, so there is no point to the ceremony of writing down those proofs in a machine-checkable format.

Re: Diminishing returns of static typing

#142

Post by tonyg » Mon, Oct 02, 2017, 5:22 PM UTC

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.

Not unless you think assembly language or machine code are statically typed.

Re: Diminishing returns of static typing

#143

Post by enraged_camel » Mon, Oct 02, 2017, 5:24 PM UTC

macspoofing wrote: post #60

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…

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.

Re: Diminishing returns of static typing

#144

Post by lispm » Mon, Oct 02, 2017, 5:25 PM UTC

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 ask my Lisp IDE to find callers for methods based on the sub/class of arguments.

Re: Diminishing returns of static typing

#145

Post by bjz_ » Mon, Oct 02, 2017, 5:25 PM UTC

cm2187 wrote: post #38

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

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.

Re: Diminishing returns of static typing

#146

Post by catnaroek » Mon, Oct 02, 2017, 5:26 PM UTC

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.

For optimal performance, the absence of unnecessary dynamic checks is a requirement. The presence of static checks is not, although they are useful for your sanity's sake.

Re: Diminishing returns of static typing

#147

Post by 201709User » Mon, Oct 02, 2017, 5:28 PM UTC

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.

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

Re: Diminishing returns of static typing

#148

Post by flavio81 » Mon, Oct 02, 2017, 5:30 PM UTC

What amuses me in all "static typing versus..." discussions, is that it usually it is the comparison between two camps:

Camp A: Languages with mediocre static typing facilities, for example:

     -- C (weakly typed)
     -- C++ (weakly typed in parts, plus over-complicated
        type features) 
     -- TypeScript (the runtime is weakly typed, 
        because it's Javascript all the way down)

Camp B: Languages with mediocre dynamic typing facilities, for example:

     -- Javascript (weakly typed) 
     -- PHP 4/5 (weakly typed) 
     -- Python and Ruby (no powerful macro system to 
        help you keep complexity well under control 
        or take fulll advantage of dynamicism)

Both camps are not the best examples of static or dynamic typing. A good comparison would be between:

Camp C: Languages with very good static typing facilities, for example:

     -- Haskell
     -- ML
     -- F#

Camp D: Languages with very good dynamic typing facilities, for example:

     -- Common Lisp
     -- Clojure
     -- Scheme/Racket
     -- Julia
     -- Smalltalk

I think that as long as you stay in camp (A) or (B), you'll not be entirely satisfied, and you will get criticism from the other camp.

Re: Diminishing returns of static typing

#149

Post by bjz_ » Mon, Oct 02, 2017, 5:30 PM UTC

hwayne wrote: post #96

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…

> The developer is encouraged to think of the invariants before trying to prove that their implementation satisfies them. This approach to software development asks the programmer to consider side-effects, error cases, and data transformations before committing to writing an implementation. Writing the implementation proves the invariant if the program type checks. I really wish more languages took this to the logica…

Check out Dafny, Whiley, and Liquid Haskell.

Re: Diminishing returns of static typing

#150

Post by Ace17 » Mon, Oct 02, 2017, 5:31 PM UTC

Eridrus wrote: post #35

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…

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.

Actually, refactoring browsers were pioneered by Smalltalk people.