3 ms·

Seriously tempted to print out the Pythonic NetworkElement code vs the Java style code and put it on my wall. Perfectly embodies why I love Python so much. A h

Seriously tempted to print out the Pythonic NetworkElement code vs the Java style code and put it on my wall. Perfectly embodies why I love Python so much. A humbling reminder of how far I have to go to be even near this guy's level.

alangpierce 11y ago
In fairness, Java doesn't need to be as verbose as the "Java-style code" from the talk, especially now that Java 8 (with lambdas) is out. Here's how I would write the code in Java: runWithNetworkElement("171.0.2.45", networkElement -> { for (Route route : networkElement.routingTable()) { System.out.printf("%15s -> %s%n", route.name(), route.ipaddr()); } });
- coldtea 11y ago
  What's this name() and ipaddr()? Sure, Java 8 has lambads, but have their disposed of getters and setters and added some kind of properties? If not, then the idiomatic way is not name(), it's getName(). (Of course without "unified property access", it's not that much different)
  - alangpierce 11y ago
    No, there aren't any special language features behind route.name() or route.ipaddr(), they're just getters without the "get" name. While methods of the form "getFoo" have plenty of history in Java, it's also fairly common to drop the "get", especially when the class is being used as an immutable value type. For example, both Google's AutoValue library and the Immutables library show examples of getters that drop the "get" prefix: https://github.com/google/auto/tree/master/value https://github.com/google/auto/tree/master/value http://immutables.github.io/ http://immutables.github.io/ One argument against the prefix is that immutable value types don't have setters, so it's not as important to distinguish between them. Another argument is that immutable values aren't really objects in the object-oriented sense, so accessing a field really is just a data access as oppose to an action being performed by the class instance. (I guess one aspect of Java that makes this less awkward to implement is that methods and fields have independent namespaces, so nothing stops the Route class from having both a "name" field and a "name()" method. That's possible because Java doesn't have first-class functions, so you can always determine from usage whether something is a field or a method.)
- agumonkey 11y ago
  Yes, Java pre 2010 is a thing to forget. All the fanatic ceremony can retire nobody will miss it. All languages, as soon as they have the right linguistic construct can achieve the same level of expressiveness. Turns out first class functions were priceless, and anonymous classes weren't a good enough incarnation of that, especially in the late 90s.

alangpierce 11y ago

In fairness, Java doesn't need to be as verbose as the "Java-style code" from the talk, especially now that Java 8 (with lambdas) is out. Here's how I would write the code in Java: runWithNetworkElement("171.0.2.45", networkElement -> { for (Route route : networkElement.routingTable()) { System.out.printf("%15s -> %s%n", route.name(), route.ipaddr()); } });

coldtea 11y ago
What's this name() and ipaddr()? Sure, Java 8 has lambads, but have their disposed of getters and setters and added some kind of properties? If not, then the idiomatic way is not name(), it's getName(). (Of course without "unified property access", it's not that much different)
- alangpierce 11y ago
  No, there aren't any special language features behind route.name() or route.ipaddr(), they're just getters without the "get" name. While methods of the form "getFoo" have plenty of history in Java, it's also fairly common to drop the "get", especially when the class is being used as an immutable value type. For example, both Google's AutoValue library and the Immutables library show examples of getters that drop the "get" prefix: https://github.com/google/auto/tree/master/value https://github.com/google/auto/tree/master/value http://immutables.github.io/ http://immutables.github.io/ One argument against the prefix is that immutable value types don't have setters, so it's not as important to distinguish between them. Another argument is that immutable values aren't really objects in the object-oriented sense, so accessing a field really is just a data access as oppose to an action being performed by the class instance. (I guess one aspect of Java that makes this less awkward to implement is that methods and fields have independent namespaces, so nothing stops the Route class from having both a "name" field and a "name()" method. That's possible because Java doesn't have first-class functions, so you can always determine from usage whether something is a field or a method.)
agumonkey 11y ago
Yes, Java pre 2010 is a thing to forget. All the fanatic ceremony can retire nobody will miss it. All languages, as soon as they have the right linguistic construct can achieve the same level of expressiveness. Turns out first class functions were priceless, and anonymous classes weren't a good enough incarnation of that, especially in the late 90s.