Howdy, Some more stats based on 2nd package from Brian
https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56 On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > Yes, with var you still get type checks, unlike in Python. But I have > wasted so much time debugging Python code simply because the type of a > local variable wasn't right there in the declaration that I remain > unconvinced var was ever a good idea. I have been convinced by > experience that implicitly typed local variables dramatically reduce > debugging speed. This isn't something I believed two years ago. Back > then I mostly didn't think about it. But since then I have worked a > lot with implicit typing, and it is painful. > > IDEs are not a full solution. They're better in Java than Python, I > admit, but I spend more time reading code in tools like Github and > Critique than in IDEs. > > I don't think banning var goes against the community in any way. It's > simply another style choice for improved readability and > maintainability, like everything spotless and checkstyle currently do. > > > On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau > <rmannibu...@gmail.com> wrote: > > > > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold <elh...@ibiblio.org> > a > > écrit : > > > > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau > > > <rmannibu...@gmail.com> wrote: > > > > > > > > @Elliotte while you are pretty right in terms of *compile* features > but > > > it > > > > ignores the biggest criteria for any ASF project : the community. > Even if > > > > silly, attracting people with Java 8 is born dead today (to > illustrate it > > > > just ask somebody to no more use "var" to do a PR for ex, he will > start > > > to > > > > "pfffff" ;)). > > > > > > Going off on a tangent but I would reject any PR that showed up in my > > > code review queue that used "var", regardless of JDK version. It's an > > > abomination that should never have been added to Java. It prioritizes > > > a trivial speed up in writing code at the cost of a significant slow > > > down in reading and debugging code. Working in Python for the last > > > couple of years has thoroughly convinced me that strong, explicit > > > compile time types are the right way to go. I've seen what happens > > > when you don't have them, and it's not fun. > > > > > > > I assume you never used it to write that cause you don't loose compile > > checks, you are not slower to read nor debug but generally faster cause > > readability is increased and if you miss the 35 char long type your > > preferred IDE will compensate that easily. > > It is literally similar to streams or even plain old java, it depends the > > habit of the coder but if we consider that we would also prevent foreach > > usage. > > You can also reverse it and write the exact same sentence on "not using > > var", how slow it is to read such a code where half of the chars don't > > bring any useful data or encourage palantir formatting to break on > multiple > > lines a single statement. > > So IMHO this is not something right to think nor even consider. > > > > Ultimately the point is not "do we think it is good or not", it is > > literally that if we go against the move then we go against the > community - > > keep in mind we should probably not be the primary citizens there - and > > therefore I'm not sure the point to be at Apache if we don't care about > our > > community. > > I'm clearly to stay there and enable people to join rather than staying > > alone 10 years ago (happy anniversary java 8 ;)). > > > > > > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
