Re: News for Java?
Lew wrote:
See? It's not the terseness or verbosity that makes trouble. I aver that
more verbose languages, up to a point, make it easier to maintain code
later on. Arne may well be right that it's COBOL's verbosity that helps
it survive.
Travers Naran wrote:
I agree that there is a Laffer-curve for verbosity. Super terse like
old-school FORTRAN & C is bad, but so is over-written, over-commented code.
There is a happy medium. But I think { get; set; } is in the happy medium.
Travers Naran wrote:
Boilerplate doesn't confuse -- it hides. I work with JPA classes
with 20
fields or more, and 90% of the getters/setters are boiler plate to work
with JPA. People then place methods that do things higgledy-piggledy
throughout the boiler plate, or will make one getter or one setter do
So it's not the boilerplate that's the problem but higgledy-piggledy
programming. The boilerplate, if it avoids higgledy-piggledy, actually
makes code easier to read.
Let's not blame the wrong thing here. It's higgledy-piggledy that is at
fault, not boilerplate code.
And IDE generated boilerplate encourages it. Reducing boilerplate to a
standardizes shot-cut is good all around, IMHO.
None of my IDEs have *ever* generated 500 getters and setters as so-called
"boilerplate". If your table has 20 columns or more, then of course your JPA
entity will have 20 fields or more, and they all need to be gotten and set by
the persistence framework, so they all need getters and setters. JPA
generates all the accessor methods next to each other, and doesn't put a lot
of "higgledy-piggledy" into them - just plain vanilla. Even when I let the
IDE (Eclipse or NetBeans are what I've used) generate a JPA entity, I don't
get unreadable or disorganized code.
I challenge your assertion. Maybe your IDE settings need adjustment, but you
aren't proving anything about getters and setters getting out of hand.
Travers Naran wrote:
Not in a 500 lines of getters & setters randomly placed (I kid you not).
Lew wrote:
You call that boilerplate? Nonsense. "I don't think that word means what
you think it means."
Travers Naran wrote:
No, I do know what it means.
http://en.wikipedia.org/wiki/Boilerplate_text#In_object-oriented_programming
That says, " The definitions of these methods can frequently be regarded as
boilerplate." It doesn't define "boilerplate", so I don't know why you posted
that link. It points out that *because* getters and setters (without
higgledy-piggledy) can be boilerplate, it makes sense to generate them. It
makes the opposite point to what you're trying to say, and again, it does not
define the term.
I'm now convinced that you don't know what "boilerplate" means.
Using IDEs to speed coding instead of syntactic sugar leads to
higgledy-piggledy code in production. IDEs allow users to create getters and
No, it doesn't. You have not established that. Your evidence is suspect, and
the conclusions from it not well founded. You're not even using terms in
their correct meanings.
setters without caring how the source is generated. And often the class will
So do emacs and vi.
evolve with fields being added or replaced new methods added at the end of the
class and the new getters/setters appearing below that. The ordering of the
Again, not an argument against getters and setters, but against messy coding
practices.
code is by accident, not design, because the programmer found it easier to
rely on the IDE instead of their own deliberate choice.
"... because ..."? You have not offered evidence of causality, and you have
not said anything against getters and setters, only against sloppy coding, and
I agree with that.
With syntactic sugar, a programmer will place their field definition in the
one block, and because they are not relying on Eclipse to auto-generate the
getter/setter, you reduce code chaos.
Baloney. Of course people will rely on their IDEs to generate code - that's
independent of whether getters and setters are a good or bad idea.
Travers Naran wrote:
Iway ancay eadray igpay atinlay, utbay ouldway ouyway antway otway
eadray isthway allway aydway?
Lew wrote:
That is a false argument. We aren't talking about Pig Latin, and if we
were we'd expect anyone who deals with it professionally to be able to
read that all day without difficulty. We expect our professionals to be
*trained* in their profession. So yes, a professional Pig Latiner would
"want" to read that all day, of course - duh. It's obvious.
Travers Naran wrote:
Professional electricians can sort out randomly laid out wiring, but
professionals would never lay out wiring randomly. Just because a professional
programmer can read chaotic code doesn't mean it's acceptable to allow it.
Trying another analogy? This one doesn't prove that getters and setters are
bad either. I am not advocating chaotic code, only pointing out that getters
and setters /per se/ are not indicative of it.
Continuing the electrician analogy, electricians follow conventions (red =
hot, black = ground), and they don't have to read labels attached to the wires
to figure out which wire is hot.
You should drop that analogy. It's not proving anything.
For Java, the equivalent of red=+, black=- would be:
public int size { get; private set; }
Not inherently. You'd like to think so, but actually the equivalent is
'getX()' and 'setX()', and to "read labels" is not a bad thing, at least not
in software, and I think not in electricals, either. Regardless, just because
you've poetically analogized the two disciplines doesn't mean you've
established anything.
While this Java:
private int size;
public int getSize() {
return size;
}
private void setSize(int x) {
size = x;
}
Is the electrical equivalent of two blue wires with two labels wrapped around
it. A professional electrician could live with wiring like that, but he
shouldn't have to.
If you say so. To me, 'getSize()' looks black and 'setSize()' looks red, but
maybe I'm just a bit better trained in Java.
Don't worry, you'll improve with practice.
A professional Java programmer can live with boilerplate like the above, but
he shouldn't have to.
I don't mind. Don't do me any favors, ok?
Travers Naran wrote:
Clarity & conciseness are the skills of a professional programmer.
Lew wrote:
Correctness trumps all. The verbosity of Java enforces correctness.
Overly concise is not clear and is not better than overly verbose.
Travers Naran wrote:
But I don't think a getter/setter short cut is "overly" concise, and explicit
code for getter/setter is overly verbose, in my opinion.
And I don't see how verbosity in the code is a sufficient condition (or even a
necessary condition) for correctness. To me, the best ways to ensure
correctness while coding are:
No one said that it is, only that terseness isn't.
1. A programmer can read an operator or method call and can quickly and
correctly come to the right conclusion about its behavior. The more words that
have to be parsed to reach the right conclusion, the more likely the
programmer in his haste or tiredness will misread the code, in my experience.
You need more experience. I find explicitly spelled accessors and mutators
much harder to misinterpret than you claim, and "haste or tiredness" to be
pathetic excuses for failure in diligence, completely lacking in merit.
Lew wrote:
We get your oh-so-precisely-defined "conciseness" in Java by code idioms
like encapsulation, not by "del (froz +{ || a i /= }- $" styles of syntax.
Travers Naran wrote:
This is a straw-man argument. You are deliberately conflating obfuscated C
with a getter/setter short cut.
No, I'm pointing out that terseness as such is not a goal. It's not straw
man, it's /reductio ad absurdum/. Get your rhetorical techniques straight.
Furthermore, you achieve terseness in Java not by excessive syntactic sugar
but by intelligent factoring of methods, choice of names and good code idioms.
Arne Vajh??j wrote:
The true masters can write concise code that is easy to read.
Lew wrote:
And correct. The true masters make things as concise as appropriate, not
as concise as possible.
Travers Naran wrote:
We agree there, but I don't think Java makes things as concise as appropriate.
That's true, you don't think that.
Travers Naran wrote:
I think I understand what you are getting at, but I don't believe that
has
anything to do with replacing boiler plate with syntactic sugar.
Well, apparently you aren't very clear on the meaning of "boilerplate".
Sugar in excess causes diabetes.
And not enough leads to hypoglycemia. You and Arne are arguing from the
excluded-middle, and I don't think I can argue reasonably with you if you
exclude the idea that there is an acceptable level of conciseness (& conversly
for me an acceptable level of verbosity).
On the contrary, not only did I not exclude the idea, I proffered that very idea:
- "I aver that more verbose languages, up to a point, make it easier to
maintain code later on." See the "up to a point"?
- "The boilerplate, if it avoids higgledy-piggledy, actually makes code easier
to read."
- "Overly concise is not clear and is not better than overly verbose." Note
the promotion of a middle way there.
- "Sugar in excess causes diabetes." Not a polemic against sugar, but a call
for moderation.
- "Some of that verbosity is useful ..." Hardly an exclusion of the middle,
now is that?
- "The true masters make things as concise as appropriate, not as concise as
possible." A direct statement of middle ground.
So what the blazes are you on about? You have apparently ignored what I said
in a desire to disagree with me even when I say things for which you wish to
claim credit.
For example, I like the explicit exception declaration and enforcement -- it
makes my life easier. But Java gives us the ability to be concise by
collapsing several related exceptions declared to one: IOException.
That's all I and the others are arguing for: sane conciseness. Not a return to
hyper-terse C.
And I'm arguing for sane verbosity. Not higgledy-piggledy.
--
Lew
Ceci n'est pas une pipe.