Still using java? Lombok can make you more productive • Hacker News Board

Re: Still using java? Lombok can make you more productive

#21

Post by vladev » Mon, Aug 03, 2009, 2:29 PM UTC

If you are lucky to be using scala a simple bean he showed is like:

case class Mountain( val name: String, val latitude: Int, val longtitude: Int, var country: String)

For the above code you get a nice factory like

Mountain('name', 11, 12, 'nowhere')

with hashCode, toString and equals. Plus that you can use this class to decompose it using pattern matching:

mountain match { case Mountain(name, _, _, country) => println(name + ' located in ' + country) }

The future is here - it's just not evenly distributed:

http://scala-lang.org

Re: Still using java? Lombok can make you more productive

#22

Post by adammarkey » Mon, Aug 03, 2009, 2:46 PM UTC

brown9-2 wrote: post #11

I was a little bit confused when the speaker kept referring to "yava" until I realized he meant "java". Neat tool, but I really don't see this being that much of a time-saver over the built-in tools that Eclipse or Idea has for this. In addition, using annotations to generate things like "cleanup" blocks around a stream seems dangerous in the long run to me - I don't like having any part of the flow of my code being…

Pronouncing "Java" like "Yava" is definitely a Dutch thing - I was building a Java based financial system for a bank in the Netherlands and it took a while to get used to the way they pronounce it too :)

Re: Still using java? Lombok can make you more productive

#23

Post by Hexstream » Mon, Aug 03, 2009, 3:34 PM UTC

stcredzero wrote: post #17

10ren wrote: post #2

It's a cute idea, to use annotations to generate getters/setters etc, instead of generating source code (IDE style). A good strategy for any boilerplate that a particular project requires. Will other tools find this code? E.g. I think javadoc is source-based, and I don't know if it will invoke such annotations. I would expect the annotation spec to require it, for annotations that can create methods etc, but I'm just…

Why are we still programming in text ? We spend so much time now with making fancy editors and IDEs that make souce code appear like hypertext. This shows that we have outgrown text. Why aren't we programming in some sort of hypertext that makes showing/hiding this stuff trivial? (Just for starters.)

"Why aren't we programming in some sort of hypertext that makes showing/hiding this stuff trivial?"

http://en.wikipedia.org/wiki/Outliner

Not a new concept, but could certainly be applied way more often than it is.

Re: Still using java? Lombok can make you more productive

#24

Post by keefe » Mon, Aug 03, 2009, 4:01 PM UTC

I'm highly unlikely to add another dependency to make the code look a bit nicer. Particularly a dependency I have to run all my code through. Typically, my model objects are simple java beans with private fields at the top and it's pretty clear to me what is what. I try to keep this stuff really separate, clearly define a set of model classes, then a set of service classes to manipulate the model, a set of manager classes (or spring) to maintain memory footprint and a set of threads managing execution. I do prefer to AS3 style of getting with the object.field syntax, but what can you do? Regardless, I think the bulk of time is spent designing the classes and their interactions and only a small amount of time actually keying them in. I don't mind a bit more overhead when creating model classes - it correct indicates to me that adding such a class is really a big change in the system, as it typically is.

Re: Still using java? Lombok can make you more productive

#25

Post by steveklabnik » Mon, Aug 03, 2009, 4:35 PM UTC

stcredzero wrote: post #17

10ren wrote: post #2

It's a cute idea, to use annotations to generate getters/setters etc, instead of generating source code (IDE style). A good strategy for any boilerplate that a particular project requires. Will other tools find this code? E.g. I think javadoc is source-based, and I don't know if it will invoke such annotations. I would expect the annotation spec to require it, for annotations that can create methods etc, but I'm just…

Why are we still programming in text ? We spend so much time now with making fancy editors and IDEs that make souce code appear like hypertext. This shows that we have outgrown text. Why aren't we programming in some sort of hypertext that makes showing/hiding this stuff trivial? (Just for starters.)

Text is the universal interface. It's the Way of Unix. As far as showing/hiding this kind of thing, vim at least can collapse function definitions, I'd be suprised if other editors could not.

Re: Still using java? Lombok can make you more productive

#26

Post by steveklabnik » Mon, Aug 03, 2009, 4:37 PM UTC

ShabbyDoo wrote: post #12

radu_floricica wrote: post #7

I always disliked this way of using OOP. If you use data classes so much, why don't you make an actual DataClass and be done with it?

Because your code would be more difficult to read. mountain.getLatitude() vs. dataClass.getDataElement("latitude"); It's the same reason I use XMLBeans (a schema-based codegen) for serializing/deserializing XML documents. Rather than writing mountainElement.getAttribute("latitude"), I can say mountain.getLatitude().

And property-esqe syntax would be even nicer:

    mountain.latitude

Re: Still using java? Lombok can make you more productive

#27

Post by gchpaco » Mon, Aug 03, 2009, 4:57 PM UTC

brown9-2 wrote: post #15

ShabbyDoo wrote: post #14

Earlier quoted context omitted.

>I really don't see this being that much of a time-saver I don't either, but I do agree with his argument that it will make code more readable. And, w.r.t. the auto-finally block thingy, badly implemented exception handling is a common cause of error in "maintenance mode" codebases. [Yes, code reviews SHOULD happen, etc.]

I think I feel the opposite - that this might make the code a little less readable, unless you know exactly what @Closeable (or whatever it's name was) does. But, to each his own...

The way the Java annotations are defined, it is almost always necessary to understand all annotations before modifying the code. It doesn't have to be this way, but the annotation processor has sufficient power to force it to be this way in practice.

Re: Still using java? Lombok can make you more productive

#28

Post by antonovka » Mon, Aug 03, 2009, 5:46 PM UTC

radu_floricica wrote: post #16

ShabbyDoo wrote: post #12

Earlier quoted context omitted.

Because your code would be more difficult to read. mountain.getLatitude() vs. dataClass.getDataElement("latitude"); It's the same reason I use XMLBeans (a schema-based codegen) for serializing/deserializing XML documents. Rather than writing mountainElement.getAttribute("latitude"), I can say mountain.getLatitude().

In this case it would probably be something like: mountain.getDouble("latitude") With at least two advantages: I'm pretty sure what getDouble will do, as opposed to getLatitude which may query google maps for all I know, and it can be processed in abstract ways. You can have operations which work on any structure: serialization, encription, logging, persistence, hash codes, sorting, raporting and a lot more. Edit: It…

In throwing away type safety, you're trading fewer characters for much more fragile code.

The Scala example in the comments demonstrates that you can have your cake and eat it too:

case class Mountain (val name: String, val latitude: Int, val longtitude: Int, var country: String)

It's concise and type-safe, and can readily be used with more powerful aggregate constructs.

Re: Still using java? Lombok can make you more productive

#29

Post by jefffoster » Mon, Aug 03, 2009, 6:02 PM UTC

stcredzero wrote: post #17

10ren wrote: post #2

It's a cute idea, to use annotations to generate getters/setters etc, instead of generating source code (IDE style). A good strategy for any boilerplate that a particular project requires. Will other tools find this code? E.g. I think javadoc is source-based, and I don't know if it will invoke such annotations. I would expect the annotation spec to require it, for annotations that can create methods etc, but I'm just…

Why are we still programming in text ? We spend so much time now with making fancy editors and IDEs that make souce code appear like hypertext. This shows that we have outgrown text. Why aren't we programming in some sort of hypertext that makes showing/hiding this stuff trivial? (Just for starters.)

You might be interested in some of the ideas of Subtext (http://www.subtextual.org/).

"Subtext takes the position that both text and diagrams have the same inherent limitation: they are paper-based media. Subtext represents programs as complex data structures that can not be fully printed out in a human-readable form. Text and diagrams are used to interactively present the program, not as a source encoding of it. This is the same approach taken by WYSIWYG applications like word processors and spreadsheets. Subtext is WYSIWYG programming."

Re: Still using java? Lombok can make you more productive

#30

Post by stcredzero » Mon, Aug 03, 2009, 6:33 PM UTC

steveklabnik wrote: post #25

stcredzero wrote: post #17

Earlier quoted context omitted.

Why are we still programming in text ? We spend so much time now with making fancy editors and IDEs that make souce code appear like hypertext. This shows that we have outgrown text. Why aren't we programming in some sort of hypertext that makes showing/hiding this stuff trivial? (Just for starters.)

Text is the universal interface. It's the Way of Unix. As far as showing/hiding this kind of thing, vim at least can collapse function definitions, I'd be suprised if other editors could not.

Hypertext-like linking and hiding is so universal nowadays, why do we have to parse whatever language just to achieve it? That's a lot of complex programming work we could avoid, and channel that effort into making cooler tools.

(It's not just parsing. We have to write little tools to take the parsed code, then infer relationships within it. Why not just make explicit links?)