Things I Was Wrong About: Types • Hacker News Board

Re: Things I Was Wrong About: Types

#121

Post by aembleton » Sun, Sep 27, 2020, 2:07 PM UTC

aazaa wrote: post #95

> Type inference: because having to write out every type, however obvious, is an incredible waste of time. Person me = new Person(); is ridiculous. let me = new Person(); may seem like a small improvement, but spread over the body of an entire program and generalized to all sorts of contexts means that type annotations become a tool you employ because they’re useful — for communicating to others, or for constraining…

You might enjoy Kotlin. Type inference, with full compatibility with Java libraries and ecosystem.

Similar to Rust, you can just write `val me = Person()`. No need for the new keyword.

Re: Things I Was Wrong About: Types

#122

Post by mplanchard » Sun, Sep 27, 2020, 2:09 PM UTC

diminish wrote: post #30

To play against the current wave, and give a contrarian pov: I'm grown up with statically typed languages from C/C++/C#/Java and later and didn't know about dynamic languages till recently. 1. Which types are we talking about? - In earlier static-typed language, the processor-based types `uint64` looked very strict, optimized the code for hardware architecture. - Having mathematically and ontological correct types is…

> 2. When you want to implement a method which applies to multiple libraries, you end up writing `fooString`, `fooInteger`, `fooDatetime` etc (or foo(String), foo(Integer)) etc. DRYing is too hard. So you end up writing 10x more methods

This is only a problem in typed languages without generics (like go) or without sum types (like go). With generics, the compiler takes care of writing fooInteger, fooDatetime, etc. With sum types, the compiler verifies that you’ve handled all of the cases in your foo function.

Re: Things I Was Wrong About: Types

#123

Post by adnzzzzZ » Sun, Sep 27, 2020, 2:11 PM UTC

JackMorgan wrote: post #82

Types are controversial because we can't measure engineer productivity. Full stop. I see people on here arguing that they are faster one way or the other, yet we have absolutely no empirical evidence for such a claim. What makes it more complex is that "fighting with types" often takes one out of the flow in a different way than usual progamming challenges. Since it's unmeasurable, we cannot see the effect of product…

I personally believe that productivity differences depend mostly on the programmer's personality. Certain types of personalities will be more productive with statically typed systems, others with more dynamically typed ones. If this is the case then the measurement problem becomes one of personality assessment rather than anything else, and even when we manage to get this measured correctly, because it's a personality issue, we'll still have people arguing cars or bicycles without facts being able to help at all (except to point that it's mostly a matter of preference so the discussion is pointless).

Re: Things I Was Wrong About: Types

#124

Post by eru » Sun, Sep 27, 2020, 2:11 PM UTC

pavel_lishin wrote: post #118

A lot of people in the comments are saying how they started off in Java, or C, and hated types, but eventually grew to love them. I started off in PHP. It was wild. Anything could be anything. Refactoring was a nightmare. Our codebase was littered with mystery variables like $hold, $hold1, and $holda, which were re-used all over the place. (Granted, this two other problems entirely orthogonal to types.) Then I got a…

Apropos PHP: I hate it with such as much passion as the next guy, but I am quite impressed with what Facebook managed to do with Hack! (Including adding lots of types.)

Re: Things I Was Wrong About: Types

#125

Post by jenscow » Sun, Sep 27, 2020, 2:11 PM UTC

aazaa wrote: post #95

> Type inference: because having to write out every type, however obvious, is an incredible waste of time. Person me = new Person(); is ridiculous. let me = new Person(); may seem like a small improvement, but spread over the body of an entire program and generalized to all sorts of contexts means that type annotations become a tool you employ because they’re useful — for communicating to others, or for constraining…

Personally, I prefer the type names to be at the start of the line, so I don't need to scan to the end of the line (or guess based on a function name).

But I agree, it's a waste to type it all out. So I use an intelligent IDE that reduces the repetitive typing:

So typing `Person.var` gives me `Person person = new Person();` or typing `Person person = ` will suggest `new Person()`

Sure, it doesn't look as appealing when creating an new object, however I get a better information when you've written something like:

    Person me = something.GetOwner();

rather than:

    let me = something.GetOwner();

Re: Things I Was Wrong About: Types

#126

Post by eru » Sun, Sep 27, 2020, 2:13 PM UTC

aembleton wrote: post #121

aazaa wrote: post #95

> Type inference: because having to write out every type, however obvious, is an incredible waste of time. Person me = new Person(); is ridiculous. let me = new Person(); may seem like a small improvement, but spread over the body of an entire program and generalized to all sorts of contexts means that type annotations become a tool you employ because they’re useful — for communicating to others, or for constraining…

You might enjoy Kotlin. Type inference, with full compatibility with Java libraries and ecosystem. Similar to Rust, you can just write `val me = Person()`. No need for the new keyword.

Though keep in mind that not all type inference is created equal.

Ie what you find in Haskell or OCaml is much more powerful than what eg Go gives you. (In Go type inference only works 'forward'.)

(I don't know enough about Kotlin to know what kind of type inference it has.)

Re: Things I Was Wrong About: Types

#127

Post by steveklabnik » Sun, Sep 27, 2020, 2:14 PM UTC

tluyben2 wrote: post #100

kybernetikos wrote: post #78

Earlier quoted context omitted.

The view I've heard expressed is that deep thought on a piece of code reduces bugs. Whether that takes the shape of religious TDD, rigorous proofs or detailed type design doesn't make such a lot of difference. I used to be fully bought into types, but I've since realised that they have a number of downsides that in many cases more than offset their benefits: 1. Ergonomic typesystems require a lot of work to happen at…

I am positive about a lot of these points for the future. Especially the performance points; that's going forward fast. But yes, that's often pretty slow; not that bothered by it for my work though. Also, linters work well for statically typed languages too; I usually don't have to compile for 100s of lines of code. If the editor does not complain, it'll probably all work fine. Like I said; do what works for you , bu…

A good post on point six: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...

Re: Things I Was Wrong About: Types

#128

Post by eru » Sun, Sep 27, 2020, 2:14 PM UTC

echelon wrote: post #3

I followed a similar trajectory. Types were the bane of my early career. Hideous, extraneous. But really, they're the light at the end of the tunnel once you've worked your way though the dynamic / weak typing minefield. It took me a lot of Python, Javascript, and Ruby for me to get there, but now I'm way more comfortable on the other side. The correct type system is actually way more expressive than not having stron…

Sum types even work when you actually have the multiple of the same return types. (Ie in Haskell `Either String String` works just as well as `Either String Int`; the types don't have to be distinctive.)

Re: Things I Was Wrong About: Types

#129

Post by wutbrodo » Sun, Sep 27, 2020, 2:16 PM UTC

I which there was a little more elaboration on _why_ he originally disliked types so much. This perspective is still very strange to me, as the value of types seems self-evident for systems more complex than a script, and I'd like to understand it better. As it stands now, my only assumption is that this comes from the place the author is coming from: people who don't think types are useful are generally coming from a place of ignorance.

This feels facile and self-serving though ("people who disagree with me don't know what they're talking about"), so it's more likely that I have a blind spot. Are there any current or former type-haters that can help shed light on their perspective?

EDIT: I should note that my production experience is primarily with (modern)C++ and Python, so I don't even have the benefit of more modern static typing systems like Rust's.

Re: Things I Was Wrong About: Types

#130

Post by temporallobe » Sun, Sep 27, 2020, 2:18 PM UTC

pavel_lishin wrote: post #118

A lot of people in the comments are saying how they started off in Java, or C, and hated types, but eventually grew to love them. I started off in PHP. It was wild. Anything could be anything. Refactoring was a nightmare. Our codebase was littered with mystery variables like $hold, $hold1, and $holda, which were re-used all over the place. (Granted, this two other problems entirely orthogonal to types.) Then I got a…

Even though I learned C/C++ in school, I started off my career with a typeless language, Perl. I loved it for its simplicity and power to quickly spool up working code, but realized it was problematic to use for large projects for many of the same reasons you state. I then switched to a Java project and was immediately frustrated with types because of how verbose it was, but after a while I came to appreciate just how beautiful and pragmatic it was, especially in its ability to help avoid so many runtime bugs that have been the bane of my existence in the Javascript, Clojure, and Ruby world.