Hacker News Reader

Comment by nicoburns | Hacker News Reader

That doesn't stop you having to type e.g.

String foo = "bar"; String baz = foo;

The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.

View on HN

I thought the complaint was about the logic duplication, not the extra keystrokes. If you want type inference you already have auto. If you want to minimize your keystrokes, you're using the wrong language to begin with, whether there's type inference or not. C++ is designed for writing software robustly, not quickly. (<-- This is not a trivial or obvious statement btw. It took me several years to grasp this. And I viewed C++ from an entirely different perspective when it finally sunk in for me that I would appreciate C++ much more if I decided to make minimizing keystrokes a non-goal.)

> If you want type inference you already have auto

or auto&&. Did you really intend to make a copy?

You probably did intend it to be a copy if you're binding it to a variable and need it to be non-const (like in the example)!

Ah, but you knew that because that's how the code was written!

If it was instead

    String foo = "bar";
    auto baz = foo;

you don't know for sure. But the code compiles so it obviously ok!

No, I'm saying even in that case you know it was intended to be a copy. If you wanted that to be a reference then you'd either (a) just do the obvious thing which is to just use the original variable name instead of creating a new variable out of the blue for no reason, (b) leave a comment explaining why you're not doing the aforementioned obvious thing, or (c) use a self-explanatory variable name to provide the explanation instead of a comment.

Is it really that painful to write "String" each time? You spend at least a fraction of a second anyway to verify that you're writing the right thing, to reconsider if you should use an object or constant or refactor the function to work with a Boolean instead of a naked string; why is writing out the type such a big deal everytime this topic comes up?

I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.

To me it's not the trivial cases like this that make type inference useful. It's when you get longer types like `Arc<Mutex<HashMap<String, String>>>`. Granted, that could be solved with a `type` declaration (or `typedef` in C++) but it's still convenient to be able to say: `let mut x = Arc::new(Mutex::new(HashMap::new()));` and let the compiler figure out the rest based on usage.

> Is it really that painful to write "String" each time?

I find it more painful to read code that has too many type annotations. I also find it painful to read code that has too few, so I'd argue there's a bit of an art to it.

But languages that have type inference but allow type annotations at least allow you to try to hit that balance.

> I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.

Type inference doesn't make these errors go away.

And about your other point, it's unfair to look at just a simple case of writing "string" or not as the only thing inference provides. Although I'd argue that leaving out types where possible helps readability-- it's really the more elaborate cases or intermediate steps during a longer transformation that inference helps with. Not to mention the fact that inference in closures is also really nice.

Java now has (limited) type inference, bar. As does C++, auto. They're limited but they remove a lot of tedium.

And it's my experience that that is only a benefit to the person who wrote the code, and only for a short time.

Generally, I prefer being able to read a line of code and understanding exactly what it does. If I need an IDE and have to repeatedly try to find the definition of something then, in my opinion, that's wasting my time.

C++'s 'auto' is really useful but it's over-used IMO. I think that there's a belief that if you're not using 'auto' everywhere then you're not writing 'modern' C++. Just becuase your code compiles doesn't necessarily mean it's correct.

+1 for auto being overused. I always felt I was shouting into the void (hah) by saying the same thing... it's nice to see someone else agrees.

Code that specifies types instead of using auto is, barring compiler bugs, usually less correct. The compiler knows better than you what the type really is.

I find that types can reduce readability as well as enhance it. They add noise and make it harder to concentrate on the variable names which are often much more important than the types which are often (but certainly not always) obvious from context.

Interesting point.

I'd never have believed it myself, but find myself using acronyms instead of variable names when the type allows it.

    void foo(MyType mt, const MyOtherType& mot);

It's the variable names that are the noise, types are everything. And no, it's not Hungarian notation either in case anyone suggests it!

However, it maybe doesn't work that well with things like class member names. YMMV

I guess it partly depends on how varied your types are. In some domains you can find yourself working with 10 variables that are all strings, or all floats/integers. At that point the type isn't that helpful for distinguishing which variable is which.

I should have added that fairly liberal use of type aliases also helps.

    using B64String = std::string;

    B64String encode(const std::string& text);
    std::string decode(const B64String b64);

Reply on news.ycombinator.com