5 ms·
>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();
by mariusmg 4y ago
>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();
- dalyons 4y agoWhy? 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.
- ivanche 4y agoNow do the code review in GitHub. Ooops!
- wiseowise 4y agoI do code review on GitLab all the time, what’s the issue?
- ivanche 4y agoNo 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().
- RhodesianHunter 4y agoNever have this issue. I'm not being hyperbolic either. I review Kotlin PRs every day and am never lost for context on a type.
- Iwan-Zotow 4y agononsense this line has zero readability you're not writing code for compilers, you're writing code for people
- toqy 4y agoI 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.
- bottled_poe 4y agoThe era of strong vs weak typing debate has passed. Adopt strong typing, like a professional, or fade into the 90s web. Harsh but fair.
- dalyons 4y agopractically 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.
- bottled_poe 4y agoThe engineering trade-offs are paid somewhere, better in an objective space than a subjective one.
- dalyons 4y agoi 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!
- 3836293648 4y agoNoone is arguing for weak typing. They're arguing for type inference. They're not even slightly the same thing
- jeremyjh 4y ago
- jeremyjh 4y agoYes 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?
- kevmo314 4y agoYeah it does, I don't really know what I can do with it. A type annotation would be useful to search for.
- MajimasEyepatch 4y agoIn 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.
- mcv 4y ago> 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.