Hacker News Reader

Comment by _bxg1 | Hacker News Reader

TypeScript also has the weird reversed type declaration. I've never understood it; it's so much less natural to read. Having the type first allows you to easily mentally parse it as "A Foo named bob".

View on HN

See, that's interesting to me, because I have always read declarations aloud as "bob the Foo", even when they're written "Foo bob". Reasonable people can differ, of course. Where it's harder to differ is that is much easier to parse type-after declarations and to make a consistent syntax with them--that's why Rust et al have gone that route. To do type inference in Java (or C#) they've had to add a new keyword, `var` (and the comedic `final var` in Java), because their declaration structure just wasn't up to doing it any other way.

That makes sense. It's definitely a subjective thing and I used almost nothing but Java and C++ for my first [counts fingers] 6 years of programming, so I'm probably biased.

I'm pretty sure I've used to read them "A Foo named bob".. But I've been in TypeScript and golang land for a while now. I can kinda make sense of it because as an interface the types are what matter most, and the signature in something like F# simply be the input/return types..

It feels weird to me, too, but I'd wager you'd get used to it pretty quick, just as you get used to saying "la pelota roja" instead of "the red ball".

/me hopes he didn't completely butcher the Spanish.

> Having the type first allows you to easily mentally parse it as "A Foo named bob".

See for me it's more natural to think of it as Eric is a Person, rather than Person named Eric.

There's plenty of decent reasons imo. Its easier to parse and handle type inference (i.e. you don't need to do something silly like have a 'type' that just says "this thing is inferred" ala auto and var). You free up the left side a bit as well which means you can use something like val x = 4 instead of having to write final or const or whatever all over the place. I (and I'm sure most devs) can also just self infer the type of something based on how it's used, so I'd rather have the name of the thing first so I can move on with scanning the code than a probably obvious type.

Also, if your type is something stupidly long (ex. Java) its really easy to read something like MyAbstractFactoryBeanImplBuilder while you have a bunch of stuff in your head and space out/forget something. Humans aren't good at keeping a bunch of things in their heads, so I'd much rather just have the names of these things and then types be as a reference to return to as a "oh wait, what was this thing again?" sort of deal.

It is not weird, in fact it goes all the way back to Algol, a decade before C was invented.

And the highly popular back in the day Pascal picked it right from Algol... Scala and Go follow the same approach, if I'm not mistaken

And Swift, and Rust, and... Really the C style is the odd one out here.

> It is not weird, in fact it goes all the way back to Algol, a decade before C was invented.

As the classic "A Brief, Incomplete, and Mostly Wrong History of Programming Languages" (https://james-iry.blogspot.com.br/2009/05/brief-incomplete-a...) would say:

This criticism happens in spite of the fact that C has not yet been invented.

And then there are those of us who simply don’t want to see the “Foo” (type) part at all, just Bob (the name).

Others have mentioned the Pascal / Modula / Eiffel type languages, I’m sure, as well as even newer languages that do type inference.

I wanna see the name of the thing on the left margin, rather than AbstractBoilerPlateFactoryFactoryFactory. Or maybe, I don’t even wanna see the thing at all, and just evaluate an expression as a parameter to a function :-)

for me the trouble begins when i switch between these syntaxes when going back and forth between Java and Kotlin, which i still have to do all the time

Reply on news.ycombinator.com