News for hackers. Stuff that matters.
Re:Chris Lattner left Swift core team by ragnese on Monday February 21, 2022 @01:15PM (#30418856)
Not in the real world, though. And for similar reasons, too. Most real Java projects I end up working on/with are littered with annotations that do God-knows-what.
Re:Chris Lattner left Swift core team by geodel on Monday February 21, 2022 @01:24PM (#30418959)
In enterprise Java code is filled annotations from some random half-assed framework. While talking to developers I feel they think annotations automatically reduce code. E.g @Validation annotation somehow magically validate input data whereas right in front of their eyes code is still if/else conditions and strings manipulations.

Of course one can't make them understand as they are just following "best practices" enforced at employers.

Re:Chris Lattner left Swift core team by mypalmike on Monday February 21, 2022 @09:18PM (#30423342)
Yeah, I would say prior to annotations taking over, the Java codebases I worked with were often quite understandable. Annotations have certainly clouded things though. Spring, for instance, is great conceptually but there's way too much magic and clutter when using its annotations.
Re:Chris Lattner left Swift core team by fomine3 on Monday February 21, 2022 @09:43PM (#30423495)
Annotation is the worst one that obscure what happening. Java language needed to be improved before annotation/javaassist based approach getting so popular
Re:Chris Lattner left Swift core team by azth on Monday February 28, 2022 @01:53AM (#30497101)
It's trivial to look up the docs to see what they do. It's not unlike looking up what a function call does.
Re:Chris Lattner left Swift core team by ragnese on Tuesday March 01, 2022 @02:32PM (#30518880)
In my experience, it's much more of a momentum killer and context switch to research an annotation than a function call.

First of all, in most IDEs, it's very quick to jump to a function's actual definition to investigate such questions as "What if both of the arguments are < 0?" or "Is null an acceptable argument?". With annotations, you'll often go-to-definition and be staring at an almost empty class that hopefully has a docstring. This is because the annotations, themselves, don't actually do anything- you have to go find the code that actually checks for the annotation and does stuff.

In my experience, the docs are often not good enough when I run into a problem. I was wrestling with some strange behavior with JacksonXML some time ago, and I had a very hard time figuring out what went wrong because Jackson has so many options and they don't actually all compose well, so it's not even about figuring out what one option/annotation does- it's about figuring out what happens when I set OptX=1 and OptY=4 at the same time. Unfortunately, the docs only tell me what is supposed to happen when OptX=1 and what's supposed to happen with OptY=4, but nobody has decided to document every single combination of every single setting in the library.