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).
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?)
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.)
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.
"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."
The problem with the metaphor, is that WYSIWYG word processing is really only arranging dark rectangles on a bigger white rectangle. Programming is much more complex -- it is as complex as writing. Word processors don't have to deal with writing. Instead, they deal with typography, and large-scale structure. Semantic interrelationships are still left up to the human tool user.
I'm not sure about source-processing tools picking up these changes. I have heard that the annotation processor is very, very powerful in java, but hardly ever used.
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".
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 :)
>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.
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().
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.
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.
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.
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.
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.
retarded is too harsh :) however the same can be accomplished through macros in a way that is better integrated with the language (when debugging lombok generated code lombok tags are not of much use i would imagine, forcing one to understand the generated code).
something like:
(defdata mountain
name :setter :getter
latitude :getter
etc ...)
might not be too hard to implement on top of clos (or on top of defstruct - but clos has the advantage of already having flexible accessors) not sure about clojure.
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