

Still using java? Lombok can make you more productive - trapper
http://projectlombok.org/index.html
Use annotations to automatically generate code at compile time. This greatly reduces java's verbosity, while maintaining tools like code completion &#38; type safety.
======
vladev
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>

------
10ren
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
not that familiar with the spec.

BTW: great presentation video: showing the problem, showing the solution,
showing how to get started. It might seem like overkill, but that's the way to
sell stuff (though this one seems to be under the MIT license, ie free).

~~~
stcredzero
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.)

~~~
steveklabnik
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.

~~~
stcredzero
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?)

~~~
steveklabnik
Are you trying to say that we wouldn't have to parse hypertext? I'm sorry, I'm
not understanding your argument.

~~~
stcredzero
We'd only have to write parsers for the hypertext, not N different parsers for
the various languages.

Think about what happens. Your IDE parses your source code so that it can do
things like highlighting, identifying senders, code folding, etc. It does this
so that you as a programmer can use those tools to more easily parse it in
your head to understand it. Eventually, your code is interpreted or compiled,
which involves another parsing.

Why not just have a direct representation of the program and its
interrelationships? Languages where the compiler/interpreter make the AST
available go a part of the way there. But too many of the interrelationships
are implicit, requiring a program to do some sort of
searching/indexing/parsing to make available. Why not just represent those
directly, and have source code be a representation?

If we could make such a representation, we might even be able to transcend the
tyranny of particular languages. (Multi language VMs are somehow related
here.)

~~~
steveklabnik
I'm not sure what advantages a language in this form would have. Why bother
mandating that it be stored like this in some way? Storing programs as text
like we do now would enable a tool to display code just as you suggest, just
check out the many code-to-html tools that are available.

I'm also not sure why I'd care that my tool parses the code to do those things
for me, nor why having my brain parse the code matters in particular. If
you're arguing for Lisp's "code as AST" syntax, well, that's fine by me, but I
don't think it's a neccesity. Macros work best with sexps, it's true, but I've
never found, say, Ruby's metaprogramming to be wanting for Lisp-style macros.

Also, I'm firmly against the One True Language way of thinking. See, for
instance, Python vs. Ruby as a great example of why nobody will ever be happy
with One Language to Rule Them All. They're so close to each other, yet their
small differences cause so much argument between the two camps.

------
brown9-2
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 handled by "magic".

~~~
ShabbyDoo
>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.]

~~~
brown9-2
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...

~~~
gchpaco
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.

------
radu_floricica
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?

~~~
ShabbyDoo
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().

~~~
radu_floricica
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 also makes for easier code reuse. You make something that works with
mountains but could work just as well with houses, you don't have to play with
class hierarchies to use it on both.

~~~
trapper
If java has one thing going for it, it's the tooling. Refactoring, eclipses
compile errors as you type + quick fixes etc are the only reason to stay in
java.

If you program like you are suggesting you lose the only reason to use java,
and have to enforce your code using unit tests in a verbose language. No
thanks.

------
keefe
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.

------
jrnkntl
In the real world its the other way around :)

------
delld
cool stuff

------
licoresse
How retarded, look at Clojure instead

~~~
fogus
How cavalier of you... never mind that there are many thousands of people who
may not have a choice but to use Java. Anything that eases the pain of
boilerplate is a good thing.

~~~
licoresse
What are you talking about? Clojure is a lisp for java, written in java and
itself, published as a jar.

~~~
fogus
And your point is? Because it is written in Java and packaged as a jar does
nothing to convince my boss and team members that we should write all of our
code in Clojure. I wish it were that easy.

~~~
licoresse
I cannot help you with that. Maybe you should be on the outloook of more
interesting things to do? I don't know...

