People who picked one tech to focus their CV on and have no interest in understanding anything else. In fact they would argue that their language/framework combo is the perfect one for every single task you present them with.
Please, do not assume i don't try new stuff before dismissing it! or that i have a single language/framework combo up my sleeve.
It's only by trying and comparing processes and results that we can effectively understand the strenghts and weaknesses, because on paper any language or framework is the only one you'll ever need, promise!
Indeed. There are absolutely "needs" for all the bells and whistles and frameworks. However I feel they just get leveraged as a "matter of course" in far too many places resulting in overheads and cognitive cost that was unnecessary.
The same can be said for "Design patterns".
To put it into a more topic form. Consider "DigitalWrite()" on Arduino. Most experienced MCU devs know it's as slow as a dog. A lot of MCU devs would just go ahead and raw write the register.
I would akin this with something like:
StringUtils.isBlank() / StringUtils.isEmpty() or it's more complex variants.
These are in several different forms from vendors like Google Guava, Apache Commons, etc.
In some circumstances you are probably better off using those as the "by hand" variants are prone to errors, omissions and asymmetrical evaluations (with holes). They are also ugly if you are checking dozens of strings/fields.
However. If instead of relying on "robust" detection of empty strings, you set some rules.
Proponents of "StringUtils" will point out that:
theString.length() < 1
Will result in a null pointer exception if the string is null. Just raise your hand and say, "Strings cannot be null - a null string IS A fatal error. Move on, next."
"What if it only contains a space or white-space character?" - Then no, it's not empty. Next.
And so on. This is why the industry is struggling back and forth between hard fixed, redefined binary protocols and "free form, semi-structured" data like XML/JSON. Both have pros and cons. The former nips a MASSIVE amount of validation in the bud by heavily containing the contents to definitions. If the underlying messages structure and builders themselves will "null pointer exception" if you put a "null reference" in a string field, then you don't need to validate they are null anywhere else.
When you define the problem and solve it on paper or in you head or white boards first, before you hit code face, you can actually remove at least 50% of the code by setting up simple "adminstrative" boundaries and "ways of working". You can embed the functionality into the data itself rather than constantly fight it.
However.... if you attempt this in modern day Java, you would be crucified and forced to add the null check or call string utils dependency (100Mb).
Similar dumb shiz. "All parameters must be final". I always respond with, "So why does java have a final keyword for params then in the first place?". Then ask them to explain what "final" actually does, which they get wrong 90% of the time. Then I ask them to explain what side effects are and accept that all java code is heavily side effect coupled and most of the core APIs use side effect action.
Speaking of which.
System.out - wait... what? Is that a public member? OMFG! BURN THEM! BURN THEM!
System.getOut()
Is that's more what the modern Java man would demand? How DARE the language creators blasphemy the gods of OOP this way!
Static? A static getter? Get out!
System.getInstance().validateSession( x-> getSecurityContext(x).validateSession().getPrinciple())).getOutstreams().collectAsList().takeFirst();
Now we talking.
Home
Help
Search
Login
Register
