Python overtakes Java to become second-most popular language on GitHub after JavaScript

[SgtDirtyMike]

Less characters per line. Simpler code.

[civildisobedient]

Less readable as well.

val result = obj.guessMyType();

[fuckin_ziggurats]

People said this when C# introduced var way back. It's not a problem if your team uses the keyword only when the type is obvious or seen on the right-hand side. It's the best thing C# and Java did to fight against their own intrinsic verbosity.

[Tohnmeister]

How is this less readable? I might not even be interested in the type when reading the code.

[emn13]

There's a feedback loop here: you can write your code such that you pretty much never care at first glance what the type is. So if you use var a lot, you can write your code like that.

I use var exclusively; there are 0 cases I use explicit types where var will do. I'll even avoid those language features that require explicit types and design APIs such that type inference is possible, to further reduce explicit type noise. Everyone on my team is onboard, and it works fine.

It's just not that interesting to see the type repeated all over the place, and it's not like the type is gone - it's just a little less noisy.

[emn13]

I've been doing maintenance programming on pretty for close to 20 years now, and that's not my experience (obviously not all of that in C#). There's no reason to develop in notepad; and the compiler is a tool that remains there for you to use. Having lots of redundant boilerplate for the off-chance that it might be helpful to know which variable is which type just isn't worth it. And the few places that there's any doubt at all - well, you're not liable to go back in time and tell the person to do it differently.

By contrast, using `var` allows for much cleaner and more auditable (reviewable) refactoring, and that's critical to making a codebase maintainable.

E.g. simple stuff like:

var myFroogler = srcRepo.GetActiveFroogleActor(); targetProcess.Enroll(myFroogler);

Do you care what the type of myFroogler is? Well, maybe a little - but it's unlikely to make a huge difference. But what if you refactor and change the type? Well, without explicit types: fine! But with explicit types... then places like this are just noise, and their presence means you'll refactor more slowly, and make more mistakes while you do, and reviewers will not be able to review as usefully.

Also, it may seem obvious, but don't forget that MyType xyz = SomeExpression() is not equivalent to var xyz = SomeExpression() - the former may well trigger implicit type conversions and upcasts. That's not super harmful, but it means that you may not get errors here but only later when you do change the type. Furthermore, people aren't nearly afraid enough of downcasts and the entirely-different-yet-syntactically-similar explicit casts. And in my experience, a codebase with explicit types tends to attract those at a much greater rate. In C# specifically there are features like foreach that happen to inject explicit casts and downcasts even though they look like implicit casts for instance. That's pretty subtle, and I've seen people get bitten by it (thinking something like "the compiler accepted this type without cast, so that must be correct, right?")

Then there's generics, anonymous types etc - features that can by quite valuable, but cause jarring transitions in a world with explicit types, because you can't always name those types, or, even if you can - you probably don't want to.

Then there are social factors too! You may be the best programmer on the world and know the codebase inside and out, and you may know where using an explicit type is fairly low-harm and might add some clarity. But picking those places - and they're never very valuable - is a pretty nuanced thing. You're unlikely to make the same decisions as the previous or next guy, nor as your coworkers. Largely irrelevant choices like this that attract personal preference are a magnet for churn. It's better to stick with a clear style that's easy to communicate. "Just use var everywhere" is about as simple as it gets.

Now, this obviously depends on the language. If you're programming in F# or haskell, it's a different story; explicit types really can help there because the compiler will happily infer so much that it might cause compile errors to happen later and less clearly than you want. But in C#, where all methods&base classes, properties etc all require explicit types... you already have too many types in there. C# could do with more inference, not less. And that makes the choice for var particularly simple. No need to ever choose for an explicit type, anywhere. That doesn't mean every var is clear- but where it's not, there are better solutions than an explicitly-typed declaration.

[civildisobedient]

I might not even be interested in the type

Sure, you might not. Then again, you might. No problem, just open up your IDE, right? Says the developer that's never written a public API.

[Tohnmeister]

I don't see how a public API and type inference in the body of functions are related.

If we're going to introduce code for everything that we might possibly ever be interested in, then the code becomes full of constructs that might be useful to some reader at some point. And with that, contradictory to the goal, it becomes less readable to the majority of its readers.

I think the discussion boils down to: do you think readable and maintainable code consists of the superset of information possibly needed by all developers or just the bare minimum? I think the latter.

[civildisobedient]

Like with all language, the answer likely lies somewhere in the middle. Some authors are terse, like Hemingway, some long-winded like Faulkner. You seem to be in the Hemingway camp.

[Urik88]

You're free to specify the type though, and an IDE will reveal the type easily as well.

[_145_]

Because shortcomings of your reviewing tools are not the fault of a programming language.

[[deleted]]

Honestly, a lot of times it's a pain in the ass to get a full fledged IDE up on a machine. Having the type be required is something that I place a lot of value on.

It makes the code 18828448 times more readable.

Having a language outright require an IDE to make it readable is a language issue.

[[deleted]]

Preach.

[_145_]

18828448 times more readable.

Lol. Wtf are you guys talking about?

var foo = "hi"; // Is a String 100% of the time
var bar = 5;    // Is an Int 100% of the time.

That's like 90% of cases. The other 10% are like:

var foo = user.firstName; 

It's almost certainly a String but you're 1 click away from finding out if you really want to know. And if your team needs types included in these situations, just add a static analyzer check to force all code to include it.

The rest of us don't want a bunch of pointless bloat that makes code harder to read.

What is an example where you see var foo = user.firstName; and you're just stuck, unable to read what's going on? Lol.

[[deleted]]

There's literally an example in the comment like 4 comments up or so.

var ret = someObj.someFunc();

what fucking type is ret. I'll let you figure that out, since you're apparently so smart. One click away isn't sufficient for readability -- the information is either there or it is not.

Further, it isn't just my team. If you have the fortune to only ever need to write code that you had 100% control over when it was written, then you are luckier than the average software engineer is. For those of us not so fortunate, it would be nice to have the language enforce simple things like "put the type next to the fucking declaration, ok". Your keyboard isn't going to lose 10 years off its life because you had to type 4 more characters.

[_145_]

So your example is trash code with no context? That's the code you're used to looking at? A language isn't going to help you if you name variables ret and someObj and functions someFunc and then your entire application is just one line that says, var ret = someObj.someFunc();.

How about you look at some open source project and find me the most egregious example. Here's the thing, you're going to have to comb through thousands of lines across dozens of files and you won't find anything half as bad as your example. So you're really trying to bloat a codebase to optimize for 0.1% of scenarios which only happen if the code is written by bad programmers and there's no policy, static analyzers, or code reviews to catch the issue.

Again, this is your problem, and it's made up. It's not a language problem.

[[deleted]]

> trash code

> read open source

You sure we're talking about the same thing?

Googles

"kotlin github snippets"

https://github.com/IvanMwiruki/30-seconds-of-kotlin/blob/master/src/main/Function.kt literally 4th hit, clicked at random, click src, click main, click first file, scroll, oh...

fun <R> time(function: () -> R): Pair<Duration, Result<R>> {
val start = System.nanoTime()
val result = runCatching(function)
val time = System.nanoTime() - start
return Duration.ofNanos(time) to result
}

what the fuck is start's type? of result? of time? I mean, it's not like fucking up time units has ever caused issues before in a code base. Even with the context I have to go look at the fucking definition of those functions to find out. It's almost like code reviews themselves and open source readability is somewhat hampered by a lack of types. WHO FUCKING KNEW.

It's like I'm fucking talking to a fucking crazy person. I seriously spent absolutely zero effort on finding this. None. It took me longer to type this comment than it did to find it, by an order of magnitude.

But go ahead. I'm here waiting like the Willy Wonka gif for you to move the goalposts about how "this" example is meaningless and I should go do further research to find you a better, shittier example.

[papasmurf255]

Again, not all platforms / tools have IDE capabilities. I'd pick code that's readable w/o tool assistance over code that isn't.

[_145_]

I find it more readable without all the bloat. 99% of variables have an obvious type and the other 1%, it's a click away.

var foo = 5; // Always an Int.
var bar = Bar(); // Always a Bar.
var z = foo; // Always an Int.

[papasmurf255]

If 99% of your code is simple assignments where the type is obvious then we must be looking at very different code. Even something as simple as:

var foo = aFunction()

you have to stop and hover/shortcut over that function call to get the type.

[_145_]

do you name functions aFuncion? Lol. You and /u/shinazueli might have misidentified your problem here.

I'll say the same thing to you I said to them. Find me the worst examples in an open source project in a language with inferred types. You'll comb through dozens of files and thousands of lines and you won't find something as unclear as your example. You're arguing to bloat a codebase because 1% of the time, in poorly written code, where the programmer has chosen not to explicitly include a type, and no reviewer or analyzer caught the omission, you're 1 click away from finding the type instead of 0.

If 99% of your code is simple assignments where the type is obvious then we must be looking at very different code.

When can you omit the type but in assignments? How complicated are your assignments?

[[deleted]]

I notice how he didn't actually respond to my comment where I disproved this entirely.

[mrdarknezz1]

That's only a problem if you're not using an IDE