Hacker News Reader

Hacker News

Comment by mariusmg | Hacker News Reader

Parent Full thread

mariusmg

>I dont really get why I would leave out the explicit types in the source code

One my pet peeves, shit like this sucks :

var f = MyStupidMethod();

View on HN

In practice, the return type is often obvious. You can write:

  val foo = new MyReallyLongUglyFactoryClass()

instead of:

  MyReallyLongUglyFactoryClass foo = new MyReallyLongUglyFactoryClass()

And you never have to use type inference. If you have a method where the return type isn't as obvious, you can always annotate it explicitly:

  val foo: Int = doSomeThing()

Do people exercise judgement about when to make the type explicit? Eh, depends on the team. But if you combine type inference with established conventions in a particular codebase (e.g. I/O calls always return IO[Foo]), you will rarely be left wondering what the type of something is.

Yes but that isn't real code. If you see something like:

> var conn = openDatabaseConnection();

Are you actually confused about what conn represents? Does it matter what the exact type is, if you already know what it is and what you can do with it?

Yeah it does, I don't really know what I can do with it. A type annotation would be useful to search for.

Maybe you need to start using IDE, instead of programming in nano.

Maybe you need to go work for GitHub to fix their code search references, instead of trying to act superior to random people on the internet.

I'm using Intellij, VSCode and Code Search for searching, why would I use GitHub for it?

I mean, you could just search for the method called, if you're REAAALLLLLYYY averse to using any IDE or editor of the last 10 years. Which would be an odd choice to base language decisions on.

Why? The compiler knows what the type is, the ide can tell you the type if you need to know - it’s redundant for you to have to type it out.

nonsense

this line has zero readability

you're not writing code for compilers, you're writing code for people

I prefer inferred types when available. Then an IDE and compiler can get together to provide further details when needed. Honestly f: MyStupidInterface = myStupidMethod(); doesn't tell me much more.

The era of strong vs weak typing debate has passed. Adopt strong typing, like a professional, or fade into the 90s web. Harsh but fair.

practically all modern strongly typed languages are adopting or already had type inference from day one, allowing you to do things like var. They give up nothing in terms of strong typing to do so. Forcing people to write manual boilerplate does not equal professional, what a strange take.

The engineering trade-offs are paid somewhere, better in an objective space than a subjective one.

i dont know what you mean by this?

Fundamentally, this is a story of technology getting better (type inference in compilers) so humans can do less work. We're not pushing the work to some other human place. We're not losing anything in safety, and we're gaining in readability, boilerplate and expressiveness. Its progress!

Noone is arguing for weak typing. They're arguing for type inference. They're not even slightly the same thing

The era of not knowing the difference between static typing, strong typing, and type inference is past. I'm the sort of professional who likes to learn computer science.

> you're not writing code for compilers, you're writing code for people

i agree, thats why i don't want to clutter my code with annotations designed for the compiler, not humans. Type inference is a _good_ thing for readability.

You can just the type hints in the IDE for bad code like the above example. But glancing through my code, that is never an issue in practice because code reviews should have caught the poorly named variable and method.

Since the actual size of the code base isn't an issue in the modern world, I personally like that the Kotlin ecosystem discourages the use of esoteric names and non obvious abbreviations. Once you write and read enough of it you stop making poor choices.

Nonsense is doing compiler work yourself, even bigger nonsense is duplicating for zero reason.

Now do the code review in GitHub. Ooops!

I do code review on GitLab all the time, what’s the issue?

No compiler there so the compiler can't tell you the type. No IDE there so the IDE can't tell you the type. You're at the mercy of colleague(s) not to write code like var request = service.call() or, worse, var b = getResult().

Never have this issue. I'm not being hyperbolic either. I review Kotlin PRs every day and am never lost for context on a type.

> One my pet peeves, shit like this sucks :

> var f = MyStupidMethod();

Yeh, but so does:

  List<MyWeirdoFooClass> myWeirdoFoos = new ArrayList<MyWeirdoFooClass>();

Sometimes it's clear what it is. Sometimes you don't really care. Sometimes you do. You can still make it explicit when you need it to be explicit.

Reply on news.ycombinator.com