• Darren (unregistered)

    I think the real WTF is Java. I've been programming in all sorts of languages for the better part of 40 years, but when I see any Java it's just an unreadable mess full of arcane invocations and unwieldy syntax. I think I'd rather try and program in Brainf*ck on a 16-character 2-line display using just arrow keys than try and write - or worse, maintain - something in Java.

  • Rob (unregistered)

    Lambdas in Java are definitely not the same as anonymous classes. Instead they are implemented using dynamicinvoke: https://blogs.oracle.com/javamagazine/post/understanding-java-method-invocation-with-invokedynamic, https://www.baeldung.com/java-invoke-dynamic

  • (nodebb) in reply to Darren

    Been there, done that. Still wear the T-shirt. Only difference is that the keyboard entry had an approx. 1 second delay. (It was an-house developed controller that used an 8-bit CPU which was "a bit" overloaded.)

  • (nodebb)

    Thing is, you don't need functional programming just because it's there. But people try to stay "cool" thanks to languages like Ruby, Python, whatever else nowadays rather than use their language the way it was intended. C# has a similar issue in that it keeps "evolving" to try and be like Smalltalk or whatever crap to appeal to the hipsters rather than just be a solid all-around language. Lambdas are cool, but were they really needed? I'm not so sure.

  • matsch (unregistered)

    urgh

    Why do they use anonymous classes instead of lambdas? Intentional obfuscation? Still getting payed by lines of code? (better update your code formatter to leverage that)

    And Java 8 already has a perfectly fine null-wrapping functional data type - it's called Optional. Just replace apply() by map() and remove everything else...

  • (nodebb) in reply to DocMonster

    Lambdas are just functions, so of course they aren't necessary; you could just define a function normally and use it the same way. Lambdas improve readability a bit when you need a trivial function to use as an argument to some other function and not need again. A good example would be something like sort(list_of_strings, lambda: replace(" ", "_", s)).

    The submission decreases readability.

  • Alexander Malfait (unregistered)

    This would be the clean way to do this in Java 8 syntax:

    return new BankConnection(
            Optional.ofNullable(account.getIban()).map(Iban::new).orElse(null),
            Optional.ofNullable(account.getBic()).map(Bic::new).orElse(null),
            account.getOwner()
);
  • urielsalis (unregistered) in reply to Darren

    You can write ugly code in any language. Java itself its great and can be very readable(on top of performant), specially in newer version, but the types of developers that write this kind of code in Java are also the types of developers that would write it in Python, C, or whatever other language you consider the best

  • WTFGuy (unregistered)

    'Zactly. Lambdas are great when the amount of "ceremony" needed to create a named callable function (or event handler) is bigger than the function itself.

    But if overdone then you get a coding style that amounts to nothing but a long chain of nested lambdas. Congratulations: you've invented something halfway between APL & old fashioned GOTO-filled spaghetti code. It becomes very hard to keep all that nesting code state in your head as you try to comprehend what's going on.

    A named function is a form of encapsulation to hide the gory details at the point of invocation. Even waaay back in the "structured programming" days this was recognized as good for comprehension.

    Another common dev side effect of excess lambdas is it encourages cut and paste coding. Need a null-check? Just C&P the lambda from someplace else rather than implement a named function to do it. Good luck finding and fixing all the instances of C&P once a bug is found in one of them.

    Definitely a two-edges sword and on that is still faddish, and therefore overused IMO. And most perniciously, mindlessly overused.

  • (nodebb)

    Just like you have grand and pathetic thefts, like stealing a Monet painting from a french museum vs stealing a chocolate bar at a convenience store, you have different levels of resume padding: azure data-lake-bricks elastic-kubernetes-docker vs using Java lambdas for no good reason.

  • Willy (unregistered) in reply to Darren

    The type of developer that came up with this would mess up in any language....Java must be doing something right to have been the most popular language for many years

  • (nodebb) in reply to Rob

    Lambdas in Java are definitely not the same as anonymous classes

    It might have been a comment based on C++ >=11 lambdas, which are either just a function or an anonymous class with an operator () member function, depending on whether the capture specification is empty. (If there's no capture specification, it doesn't need to be a class, because there would be nothing to store in the object.)

  • (nodebb)

    And you just know it's going to throw a NullPointerException because the third parameter is null.

  • (nodebb)

    Actually, I don't see any use of lambdas as such in the example.

    It's just using two anonymous classes inside the apply method. Of course, in Java, lambdas are implemented using anonymous classes but the syntax used here is valid in earlier versions of Java provided you have defined the Function interface.

  • Duke of New York (unregistered)

    Bank code? Say no more. I had a job providing a Java SDK to banks around 2015 and most of them were sitting very comfortably at Java 6, thank you very much. They still haven't finished migrating off COBOL and you expect them to chase Java trends?

  • Duke of New York (unregistered) in reply to Rob

    That's an important distinction to anyone who is implementing a Java compiler or runtime, i.e. almost nobody.

  • Jeremy (unregistered)

    This is just following the way of throw away society. Use it once then throw away. One time passwords and one time credit cards are common already. Now we see one time functions, and one time classes. When will we see one time pods or services?

  • xtal256 (unregistered) in reply to DocMonster

    The difference is that Smalltalk had things like lambdas built in from the start, where as every other language has it tacked on with an awkward syntax.

  • (nodebb)

    Fun fact: Though the specific Function<T, V> interface is documented as having been introduced in Java 8, the code demonstrated here could have been implement in Java 5 with a self-defined Function<T, V> interface. That might explain, why no lambda expressions were used, because the same could have been written, without even changing the over-use of functional programming, as

    public final class Account2BankConnection implements Function<Account, BankConnection> {
  @Override
  public BankConnection apply(final Account account) {
    final Iban iban = ((input) -> input != null ? new Iban(input))
      .apply(account.getIban());
    final Bic bic = ((input) -> input != null ? new Bic(input) : null)
      .apply(account.getBic());
    return new BankConnection(iban, bic, account.getOwner());
  }
}

    Of course, in the same manner, defining a class Account2BankConnection is useless, because instead of instantiating a new function object for every invocation, we could just have used some utility method (or better, class constructor of BankConnection, if it isn’t an external library), and then used the method reference UtilityClass::account2BankConnection or the constructor reference BankConnection::new.

    The sane form would have reduced to

    public static BankConnection account2bankConnection(final Account account) {
  final Iban iban = account != null ? new Iban(account.getIban()) : null;
  final Bic bic = account != null ? new Bic(account.getBic()) : null;
  return new BankConnection(iban, bic, account.getOwner());
}

    ...

  • (nodebb)

    ...

    Much more readable. Also more clearly showing more WTFs:

    1. It doesn’t check for account != null for .getOwner(), defeating the point of having those above...

    2. Why does it create new Iban, Bic objects at all? By all accounts, those should be immutable.

    Btw, am I the only one who would prefer the “trivial error case” to be first for readability? I much prefer

    final Iban iban = account == null ? null : new Iban(ac

    Addendum 2023-08-24 03:49: Text got cut off due to BKAC problem.

  • p (unregistered)

    Do the parameters and local variable really need to be declared final? Are we so worried about accidentally reassigning them within the scope of the function that we need all that extra noise?

  • LZ79LRU (unregistered) in reply to R3D3

    Personally I do not like using ternaries for errors. Flow control, absolutely. But when it comes to errors I prefer a big and obvious IF complete with brackets to make sure the fact it is in fact an error condition is plain to see for anyone reading the method. After all, a null is not necessarily an error state. It could be expected flow.

  • (nodebb) in reply to p

    Do the parameters and local variable really need to be declared final? Are we so worried about accidentally reassigning them within the scope of the function that we need all that extra noise?

    In trivial code like this, not necessary. But it is good practice anyway to declare for anything that won't change, that it won't change, and is it really that much noise?

Leave a comment on “Functionally Null”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article